Hacker News new | past | comments | ask | show | jobs | submit login

I give up. Something to do with the use of literal ints without width designators?



Assuming the second one is supposed to be VHDL, there are so many syntax errors that I can't figure out what the OP's intent is...


After a think, ignoring the VHDL syntax,I think the Verilog example has edge sensitive set/reset, whereas the VHDL has level sensitive set/reset? I don't write Verilog mind so I'm guessing a bit...


You are correct in the edge sensitive set/reset from a simulation standpoint. If reset is asserted, then set is asserted, then reset is de-asserted, then the flip-flop will remain in reset. It's not truly asynchronous from a simulation standpoint.

This could be fixed by using:

always @(posedge clk or rst or set)

I am guessing the thing that throws a verilog designer off the trail is that "always @(posedge clk or negedge rst)" is commonly used for asynchronous reset in ASICs (if you are using it in FPGA's except for the DCM's and as input to a clk-rst module.... stop), and this works just fine but if you want to do a d flip flop with an asynchronous SR condition, you can't use "negedge" on the rst signal.

However, synthesis will probably treat it asynchronously. Of course this is also bad because there will be a simulation/synthesis mismatch.

At any rate, the question is a bit ambiguous due to the unclear vhdl code.


You found the problem, congratulations.

Both code samples are the recommended way to generate an asynchronous set/reset flip-flop for an ASIC flow (minus my bad memory about details of the VHDL syntax).

For years, Design Compiler has forced ASIC designers to describe level sensitive pins (set or reset) as if they were edge triggered, which is correct in most cases, except the case you outlined.

So those two codes generate the exact same logic after synthesis, but you can have mismatches with simulation. And there is actually nothing you could do about it to fix the Verilog since you need your synthesis tool to understand your intent. The correction you propose is the correct one from a simulation viewpoint, but DC would reject it.

Luckily, the case where you assert both set and reset on a flop to then deassert reset are fairly rare...

I was on the IEEE standardization committee for VHDL synthesis: since then I know why [some] standards don't make sense.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: