(e-mail address removed) (john jakson) wrote in message \
[snip]
C is great for simulation, but hand translation is problematic.
(Don't know about you, but I tend to make many mistakes in the
process.)
Its a highly restricted verilog assign/always set so its fully
synthesizeable and not too diff to write same in C. Ofcourse the
assigns are written in an assign() {} and usually flow downwards. The
always() {} reg <= 's are written in reverse time order to preserve
equiv cycle behaviour. In both fns, wires/regs (uints really) are
always single writes. Now if only C had unlimited ints and would let
me use {,,} <= syntax, I'd be in HDL heaven.
In the past I've hacked up and maintained C => Verilog but that
reduced C HDL to a vulgar HDL. It was obvious that Verilog => C would
be much better result and that worked quite well only losing 2-5x in
raw c performance over pure C.
Have you considered Verilator? I've had quite a bit of success with
it -- I used it awhile back to simulate a Verilog model inside
Simulink. The speed is good, and I know Wilson recently added several
new optimizations to further improve performance.
I am aware of it but haven't followed the few oss EDA tools. If I were
using Linux I might be more inclined to try these out. I should pay
more attention to those that are good.
If you're targeting an FPGA, there's no reason not to consider
Confluence. The auto-generated C models are topologically ordered, so
you don't have to maintain a flat hierarchy. Also, there are no
restrictions on single clocks or signals greater than 32/64 bits.
I took a look at CF but I didn't find the syntax to my taste even if
though the other feature of generating x,y,z from it is interesting.
The other reason for using C is to directly master the ucf placement
file, just a fancy printf fn() {}. Of course any lang will do but I am
C/verilog focussed. Since I am doing cpu design ofcourse I have to do
a lot of other stuff in C like work on compilers & test programs at
the same time. When the cpu is done I will be back on my original lcc
based compiler with added verilog/occam support, but thats away off.
Typically I write my testbenches in Python to drive the CF generated C
models. Python is makes it is easy to construct a transaction level
testbench. And because the bulk of the computation is in compiled C,
sim performance is still top notch.
-Tom
Well any EE that writes SW code in any language has a leg up on pure
HW guys, esp if your a tool builder too. I think in the end that thats
more important, if the tools you build are really usefull, let them
go. I don't because I don't want the hassle of updating and docs &
support, but perhaps will in the future.