SystemVerilog Assertions

Although been using the system verilog for a while but have not used the SystemVerilog Assertions(SVA). We could use the Formal verification to verify one of our Arbitration logic. Thats when I realized the assertions are quite overloaded entries. Formal verifciation seems to be good idea for the logic structures of the type "more of less". Meaning small processing but doing lot concurrent processing. Writing simulation environment for such thing is a pain. I found formal verification to be complementry to the the simulation than a replacement. Its certainly interesting and should be carefully made use to cover certain part of verification.

SVA is an integral part of IEEE-1800 System Verilog languages focusing on the
- temporal aspects of the spcification
- modeling
- verification
SVA allows sophisticated multi-cycle assertions and functional checks to be embedded in to the HDL code.

Good thing is it is multi-faceted. The same can be used as assertions, functional coverage, debug and formal verification.

It kind of makes verificatione engineers to invest in SVA assertions.

Communication Protocols -1

I was just looking back at the communication protocol's that have dealt with.

1. Started with simple UART
2. Moved to simple TDM switch
3. Telecom carrier line protocol E1 still kind of TDM
4. From TDM's to packet switched ISDN BRI and PRI from Exchange side
5. TCP/IP
6. H.323 and RTP for the VoIP

Aha...TCP/IP linux software stack interested me after having looked at the Streams based ISDN stacks. But what really fascinated me how would it look if the TCP/IP could be completely implemented in hardware. Not using some dedicated processor but a real custom FSM's. Processing the data at huge rate. May be people might have done it and using it in Server space.

Although I never got to implementing the TCP/IP on the hardware but have seen several mini versions in the bursting serial communication interfaces.

1. RapidIO - Parallel version. We implemented the first version of the spec. 8-bit Physical and link layer with buffer management logic for the protocol layer. It was fun.
2. HyperTransport - which was also called as LDT
3. PCIe - serial versions of it
3. USB3 - Now.

Its been a while dealing with these protocols. Many times during these spec implementation one thing that's not given enough attention by many as to why the things way they are. Although agree not every one may need it but it's certainly very important that at least few of the top level folks know about it. Its DNA.

In case of any ambiguities in the specs it helps to decide which route to take if you knew what intent it is supporting.

I am going to be doing the post mortem of these protocols and try to get what is the basic core problem is it trying to solve. Will be taking USB3 since I am fresh with it. Others have lost touch for a while.