[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] Free synthesis tool for Verilog and other links


Ben Franchuk wrote:

> Just an Illusion wrote:
>> The problem with schematics is that they are in proprietary format, 
>> which are incompatible between tools.
>> More, synthesizer don't like them (I don't no why but when I try to 
>> give them circuit like postscript, jpeg, png files... They crush :-D).
> True, but I am visible person I like to see block diagrams and such.
> The schematic problem is one due to lack of tools rather than a poor data
> entry format.
> I would also go so far as to say even the HDL's are proprietary formats
> because of the minor diferences in compilers. I suspect most venders 
> of the
> tools don't want portablity but rather just have you to stick with 
> their product.
Some time, I'll prefer graphical view too, but it can be confusing too 
(by example, if you have a design with 10 explosed 64 bits buses and 
some logic).
I am agree, the vendors have proprietary compiling format because this 
format isn't an normalized nor standardize exchange format. Each vendor 
adapt his compiled model to their proprietary tools treatment philosophy.

The h/w exchange format are hdl (vhdl and verilog) sources, hdl netlist 
source and *edif* format. See the different h/w project on the net.

>> It seems than some peoples misunderstood what we have in a hdl code 
>> (verilog or vhdl).
> I want more choice than that, but since I am NOT FPGA vender or some BIG
> GOVERMENT AGENCY I have no say in the matter.

Wait, wait, don't make mistake.
The both main hdl language are *not* fpga specific.

The both ones are h/w modelisation language to design any h/w systems 
(digital or not, with the vhdl-ams and the verilog-a extension). The 
design can be implemented (fully or partially) in any type of 
appropriate programmable logic like : rom, prom, eprom e2prom, ram, pld, 
gal, fpga, asic...

>> With the same language, we can describe 3 main level of abstraction 
>> of the same design (or function) :
>> - The behavioral level, where you describe the dataflow treatment 
>> without any preoccupation of register transmission, synchronism 
>> implementation...
>> - The structural level (named *rtl*, for Register Transfert Level), 
>> where you describe one of the implementation possibility of the 
>> previous behavioral model. At this level, you need define the 
>> registers, the synchronism clocks...
>> - The gate level (or netlist) where you made a implementation of the 
>> previous levels, and describe like primary blocks interconnexion.
> I can't see how the behavorial level be a major level above the RTL 
> level? 

Search the processor Mark2 code, this is an old model of 8 bit processor 
given into the book :
R. ARMSTRONG : Chip-Level Modeling With VHDL; Prentice Hall, Englewood 
Cliffs,NEW-JERSEY 07632. 1989

And try to synthesize the code, or try to rewrite it like rtl model and 
you can see the difference.

Or keep behavioral description of different project on opencores.org

> All operations still have fully defined.  a <- b * c may look ok but what
> about overflow, signed vs unsigned and other parameters.
> But then too I have used a computer (PDP-8/S) that used real transistors
> diodes and other components. If something breaks you fix it, not like 
> today's
> computers. I still like to stay close to the hardware level.
> Note I am questioning the tools that can be used here, not how the F-CPU
> is implimented. The F-CPU seems to be comeing along nicely.
Just an Illusion

"The matrix is my world, I am a shadow.
Shadow in world, shadow in life. Don't try to keep me,
I am a Corpo's Killer.
Don't follow me or die..."
		The KingWalker - 1996

To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/