Re: [myhdl-list] CHIP, a myhdl like project

[Christopher F. <chr...@gm...>]

On 10/17/11 3:38 AM, Sébastien Bourdeauducq wrote:
> On 10/17/2011 09:51 AM, Jan Decaluwe wrote:
>   >  One way, and the big winner
>   >  to date, is the event-driven paradigm. That is what
>   >  VHDL, Verilog and MyHDL have in common.
>   >
>   >  It is incorrect (although often done) to call such
>   >  languages "RTL" languages. Instead, RTL is
>   >  a semantic subset of such languages. There are
>   >  other ways to do RTL, but I'm convinced that this
>   >  is the single way to do it right.
>
> Oh, come on. For synchronous systems, which is what the common mortals
> who design with FPGAs almost always deal with, the event-driven paradigm
> is just a complicated way of getting things done. Cycle-based
> simulations are simpler, faster, and also correct.
>

Ok you lost me here.  Best of my knowledge, most simulators are event 
based simulators.  They have event queues and at each simulation cycle 
the event queues are inspected.  Once all events are processed, the 
simulator moves on to the next cycle.  A cycle-based simulation without 
events and event queues would need to do a lot of explicit checking and 
unneeded execution without the queues.  I don't understand how a cycle 
based simulation without events is faster?

>> The back-end is VHDL RTL, and
>> as I noticed before, I think MyHDL would have been a
>> better choice.
>
> Then maybe you'll like my HLS prototype better? If so, please consider
> merging my patches which are needed to support it.
>
>   >  * "A hardware model written in an imperative style cannot be
>   >  synthesised"
>   >
>   >  This is wrong: an imperative style is actually very useful to describe
>   >  combinatorial and clocked RTL logic.
>   >  (...)
>   >  I agreed with the author that RTL is "low-level". However, it  is
>   >  definitely not as "low-level" as he suggests. If the starting
>   >  point is shaky, I don't have a lot of confidence in the "solution".
>
> I think he meant "imperative style for a complete algorithm", not
> "imperative style for describing what can be done within one clock
> cycle". From this point of view, it is true that the efficient synthesis
> of a complex algorithm written in imperative style is a very difficult
> problem, and that using a different "dataflow" paradigm can make sense.

I agree, I think the author poorly described the point.  And probably 
should have said "would implement an algorithm in an imperative style". 
  Given how it is worded it gives the wrong impression.

Regards,
Chris

>
> S.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct