I'd rather switch than fight!
in [FPGA]
|
From: Bernd Paysan on 16 Apr 2010 18:37 glen herrmannsfeldt wrote: > If your test bench is good enough then it will catch all static > timing failures (eventually). With static timing analysis, there > are many things that you don't need to check with the test bench. And then there are some corner cases where neither static timing analysis nor digital simulation helps - like signals crossing asynchronous clock boundaries (there *will* be a setup or hold violation, but a robust clock boundary crossing circuit will work in practice). Example: We had a counter running on a different clock (actually a VCO, where the voltage was an analog input), and to sample it robust in the normal digital clock domain, I grey-encoded it. There will be one bit which is either this or that when sampling at a setup or hold violation condition, but this is only just one bit, and it's either in the state before the increment or after. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/
From: evilkidder on 16 Apr 2010 23:40 > For example, with MyHDL you will also have to learn about latch > inference and how to avoid "unwanted latches". However, just like in > VHDL/Verilog there is a much better solution for this than using a > limited HDL: use a clocked process template by default. > I don't agree with this. Why provide such a general framework when all you really want is the "clocked process" anyway. VHDL, Verilog and MyHDL all let you make the same mistake over and over again. Cheers, Andy
From: Paul on 17 Apr 2010 02:21 On 17 Apr, 04:40, "evilkid...(a)googlemail.com" <evilkid...(a)googlemail.com> wrote: > > For example, with MyHDL you will also have to learn about latch > > inference and how to avoid "unwanted latches". However, just like in > > VHDL/Verilog there is a much better solution for this than using a > > limited HDL: use a clocked process template by default. > > I don't agree with this. Why provide such a general framework when > all you really want is the "clocked process" anyway. VHDL, Verilog > and MyHDL all let you make the same mistake over and over again. AFAIK, to avoid latch inference you need a non-sequential language, and most don't want that.
From: Jan Decaluwe on 17 Apr 2010 04:50 On Apr 17, 5:40 am, "evilkid...(a)googlemail.com" <evilkid...(a)googlemail.com> wrote: > > For example, with MyHDL you will also have to learn about latch > > inference and how to avoid "unwanted latches". However, just like in > > VHDL/Verilog there is a much better solution for this than using a > > limited HDL: use a clocked process template by default. > > I don't agree with this. Why provide such a general framework when > all you really want is the "clocked process" anyway. VHDL, Verilog > and MyHDL all let you make the same mistake over and over again. The context of the "clocked process" paradigm is synthesizable RTL code. For many engineers working on complex projects, writing such code is only a fraction of their work. For high-level modeling and verification, you can use the power of the language in its full generality. For powerful HDLs such as VHDL/Verilog/MyHDL, the synthesis coding constraints are imposed by synthesis technology, not by the language. It is easy to design a "fully synthesizable" HDL that incorporates such constraints in the language definition itself. It just seems that the market doesn't want those. I certainly don't. You are of course free to ignore that observation. Jan P.S not all latches are "unwanted" :-)
From: rickman on 17 Apr 2010 10:48
On Apr 17, 2:21 am, Paul <pault...(a)googlemail.com> wrote: > On 17 Apr, 04:40, "evilkid...(a)googlemail.com" > > <evilkid...(a)googlemail.com> wrote: > > > For example, with MyHDL you will also have to learn about latch > > > inference and how to avoid "unwanted latches". However, just like in > > > VHDL/Verilog there is a much better solution for this than using a > > > limited HDL: use a clocked process template by default. > > > I don't agree with this. Why provide such a general framework when > > all you really want is the "clocked process" anyway. VHDL, Verilog > > and MyHDL all let you make the same mistake over and over again. > > AFAIK, to avoid latch inference you need a non-sequential language, > and most don't want that. I'm not clear on what either of you are saying. I don't seem to have a problem with latch inferrence mainly because I know what causes inferred latches. It has nothing to do with sequential or non- sequential languages. VHDL has non-sequential capabilities and I can infer a latch using that. a <= b when (c = '1'); -- use "c" as a latch enable What am I missing? Rick |