Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Matthias, ~~~~~ I copied all sections from the .vho file to the right locations (configuration etc.). When I start modelsim out of the webpack enviroment to do a functional simulation, I got a warning that my core component (async fifo V3.0) is not bound - This warning can be ignored ! When I start my testbench, all outputs of my core (I also tested a simple counter core) stay unknown. ~~~~~ I assume that the "not bound" warning is related to your problem. The warning may have two reasons: a) there is a mismatch between your entity and component declaration b) the behavioral models for the CoreGenerator modules have not been bound to your project I assume that the latter is the case. CoreGenerator creates two outputs: 1) The vho files to model your generated core with CoreGenerator-specific prmimitives. As the library with these primitives is missing, your behavioral simulation failed. 2) An EDIF netlist to be merged with your synthesis results during NDGBUILD. As your EDIF netlist is there, you haven't experienced problems during timing simulation. Hope this helps, best regards Felix Bertram ___ Dipl.-Ing. Felix Bertram Trenz Electronic Duenner Kirchweg 77 D - 32257 Buende Mailto:f.bertram@trenz-electronic.de http://www.trenz-electronic.deArticle: 31801
The format of the bitstream is a secret but you can use JBits API from xilinx to access the information contained in the bitstream and change it. Miguel "Vladislav Vasilenko" <vlad@comsys.ntu-kpi.kiev.ua> wrote in message news:3B1C930E.21EEDC1F@comsys.ntu-kpi.kiev.ua... > Hi Alfredo, > > "..Xilinx keeps the interpretation of the bitstream a closely guarded > secret.." It's > quotation from Xilinx "The Programmable Logic Data Book ". > > Best regards, Vlad. > > Alfredo Benso wrote: > > > > Hi everybody, > > I am a researcher at Politecnico di Torino in Italy. > > I am looking for information about the format of the Xilinx configuration > > bit stream. Is the format public? Is there some document or file available > > explaining how to generate a stream of configuration bits for a Xiling FPGA? > > > > Anybody can help? > > > > Thanks Alfredo > > > > ----ooo---ooo---ooo---ooo---- > > BENSO Alfredo, PhD > > > > Politecnico di Torino > > > > Dip. Automatica e Informatica > > > > C.so Duca degli Abruzzi 24 > > > > Torino - Italy > > > > Phone: +39-011-564.7080 > > > > Fax: +39-011-564.7099 > > > > email: alfredo.benso@polito.it > > > > ----------ooo---ooo-------------Article: 31802
Hi Alfredo, Time ago in this newsgroup it was a thread called "XC3000A Configuration data", that maybe could answer some of your questions. I described then the few bits of the bitstream that I know. You can see the article at: http://www.fpga-faq.com/archives/25350.html#25351 Hope this helps a bit Juan-Luis Lopez Spain Alfredo Benso <alfredo.benso@tiscalinet.it> escribió en el mensaje de noticias 9fgaom$opj$1@menelao.polito.it... > Hi everybody, > I am a researcher at Politecnico di Torino in Italy. > I am looking for information about the format of the Xilinx configuration > bit stream. Is the format public? Is there some document or file available > explaining how to generate a stream of configuration bits for a Xiling FPGA? > > Anybody can help? > > Thanks Alfredo > > ----ooo---ooo---ooo---ooo---- > BENSO Alfredo, PhD > > Politecnico di Torino > > Dip. Automatica e Informatica > > C.so Duca degli Abruzzi 24 > > Torino - Italy > > Phone: +39-011-564.7080 > > Fax: +39-011-564.7099 > > email: alfredo.benso@polito.it > > ----------ooo---ooo-------------Article: 31803
if pulscnt[].q == buff[].q then
waveout = vcc;
pulscnt[].d = pulscnt[].q + 1;
zendloop[].d=zendloop[].q+1;
elsif pulscnt[].q == nieuw[].q then
waveout=gnd;
pulscnt[].d=0;
elsif zendloop[].q == 50 then
SA = sa0;
else
pulscnt[].d = pulscnt[].q+1;
end if;
Both buff[].q and nieuw[].q have values assigned (variable) but I can't get a
zendloop[] to count, and I can't get waveout to be high, longer than 1 clock
cycle.
Any help is greatly appreciated
--
Sander Ruitenbeek
tel: +31622518788 e-mail: ruitenbe@cs.utwente.nl
Article: 31804
ruitenbe@cs.utwente.nl wrote in message news:<9fkmli$l6s$1@ares.cs.utwente.nl>...
> Hi, I want to implement a state machine which runs through state SA2
> 50 times, but I can't get it to work correctly.
> WHEN sa2 =>
> if pulscnt[].q == buff[].q then waveout=gnd;
> SA = sa1;
> elsif zendloop[].q == 50 then
> SA = sa0;
> else zendloop[].d = zendloop[].q+1;
> pulscnt[].d = pulscnt[].q+1;
> end if;
> END CASE;
> END;
>
>
> The problem is that it gets through the various states very well, but
> waveout seems to be stuck to ground in SA2.
> But it shouldn't be stuck at ground, it should change to Vcc when 50
> ticks of the clock have passed
>
> What am I doing wrong? Any ideas would be greatly appreciated.
If I understand couurctle, you want the state machine to output a high
when the pulse signal goes high. Then 50 clock cycles later, you want
the output to go high again and the state machine to go to the idle
state. I will also assume that buff[] will make it go through the SA1
state without pulsing high until it gets to the SA1 state.
If these assumptions are true, you just have to recode the SA2 state
as such:
WHEN sa2 =>
if pulscnt[].q == buff[].q then waveout=gnd;
SA = sa1;
elsif zendloop[].q == 50 then
waveout = vcc;
SA = sa0;
else zendloop[].d = zendloop[].q+1;
pulscnt[].d = pulscnt[].q+1;
end if;
This will make waveout go high when the zendloop[] = 50. The problem
that may arise is in the priority scheme of the if statememnt. When
the buf[] signals are "110" (!buf[0] & buf[1] & buf[2]), the machine
may get stuck into a loop until the buf[] signals change. This loop
will not make waveout go high because zendloop[] and pulscnt[] have
the same equations and will therefor mimic each other. When buff[] is
set to 50 or less, the state machine will go to SA1 and not send
waveout high. When buff[] is greater than 50, it will never come into
play.
I hope this helps. If not let me know and I'll try to explain more.
Brian
Article: 31805hi all, I need to designg a auto increment register in a fpga (virtexII) for Arm to access the fpga internal memory. The register is suppost to be use as a src_ptr for an indirect memory access. so if an control bit, say .. "auto increment" is set, any access to another register the data_reg will increment the src_ptr. clk for arm is 35.7ns, clk for fpga is 8.9ns. I came out with a design but it is using gated clock, which I am not very comfortable with. there must be some other way, auto increment should be common?! anyone have any idea? or some link ... etc anyway here is what I come out with. for the src_ptr, a preload counter preload is control by the (wr_n==0 and src_ptr_sel and fpga_sel) from arm. value for preload is data from arm clock to the counter, + ve edge a nand gate with (fpga_sel,data_reg_sel,rd_n,wr_n,auto_increment ) from arm. if the skew between these signal is properly constraint, there should be no glitch, is should work right ? fpga_sel and data_reg_sel is decoded from the address send from arm. ( so more signel to constraint) any comment? thanks spyngArticle: 31806
> I understand why you have such a dislike of HDLs. My first exposure to > VHDL was less than pleasant. But I have returned to HDLs on a project > using Verilog and I am having a much better go of it. Actually, I don't have a dislike for HDLs, but for the tools! > Many of the problems I had were just a matter of learning what to expect > from an HDL. And then in the new release of the tools, or a different tool, what was expected is now different. > After you get some experience with a compilier, you learn > what kind of design it produces from what type of code. And then in the new release of the tools, or a different tool, what was expected is now different. > Now I very > seldom have a problem getting what I want even in very highly optimized > design. How do you know? Do you go in and check with FPGA editor? What has happened is now that the parts are so much faster, just like the x86 CPUs, one can get design implementations that are not very optimal, but meet timing. The parts are also so much larger, so taking up more resources using HDLs to implement a function, isn't such a big deal. > The only exception is when I need to use a unique architectural > feature. Other than instantiation, this can be difficult to coax. But > often there is no good reason not to use instantiation. > > So jump in and get to know HDLs. You may even like it once you learn the > flow. Er, I have been using HDLs since they first came out...I know them quite well, and have done probably hundreds of thousands of lines of ASIC, FPGA and simulation code in HDL. That has nothing to do with the actual issues that the tools have. What I would like to see is the tool vendors provide a document that shows how the constructs are disseminated. It should be deterministic, and the designer needs to know, without having to play games, or worry between revisions of the same tool, how the tools behave. The key is consistency. The other issue, that has been partially solved, is placement issues. Being able to consistently name an instance, and floorplan it.Article: 31807
> The PDP-1 doesn't contain any FIFOs. How do you know that? Do you have the schematics for the entire PDP-1 system and the peripherals? Just because it isn't labeled "FIFO" doesn't mean it isn't performing a FIFO function. I'm not saying it is, but I don't know how, unless you were either the designer of this system, or have pretty detailed documentation, you can make that claim. > If you can cite a FIFO available > as a purchasable semiconductor-based product (even using discrete > transistors) that was available before 1971, I never said there was. Go back and read the thread. The original statement was "designed the industry's first FIFO", and it depends on what "industry" one takes that to mean as to whether that statement could be true or not. There certainly were hardware FIFOs before 1971 used in the computer industry. > And yet after he clarified that he meant "semiconductor industry", you > continued to try to refute his claim. Er, no. As I said, go back and read the thread. I've said a number of times, I am not, and did not, refute the claim that it was the first available integrated circuit FIFO or how ever you want to qualify it. Others opined that it was the first semiconductor FIFO, which is what I continued to refute. Any digital designs done since 1960 would be made from semiconductors.Article: 31808
Kolja Sulimma wrote: > One of the fastest and most complex CPUs was designed using hundreds of custom > cells layouted by hand > using hundreds of highly skilled engineers AND proprietary inhouse skew analysis > tools. So you trade speed of design and speed of the part. It seems with HDL's you are fighting the language rather than gates. Just like software - machine code or compilers your pick. > This propably falls into Falk category: > "Sure, a pro can always get better results than a "stupid" compiler but for what > efford??" > > Ever seen any inhouse FPGA tools? With the marketing schemes and licensing plans and $#%! closed source you don't see any real chip information or tools that are reasonable. > Kolja Sulimma Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk Updated - Now with schematics.Article: 31809
Matthias Fuchs wrote:
>
> Hi,
>
> I encountered a little problem in the bahavioral simulation a xilinx
> core that have been generated with the core generator.
>
> All outputs of the core instances are in the unknown state ('U'). Timing
> simulation works fine !
>
> I am using the xilinx coregen with IP update #3 from xilinx foundation
> software service pack #6. I installed all updated and precompiled
> simulation libraries (including the xilinx core lib) for modelsim 5.3d
> XE (as it comes with the WebPack CD).
>
> I copied all sections from the .vho file to the right locations
> (configuration etc.). When I start modelsim out of the webpack
> enviroment to do a functional simulation, I got a warning that my core
> component (async fifo V3.0) is not bound - This warning can be ignored !
> When I start my testbench, all outputs of my core (I also tested a
> simple counter core) stay unknown.
Problem solved ! I had to load the configuration of my testbench from
Modelsim ! After that functional simulation is working ! Without that
Modelsim has no model of the cores !
Matthias
--
-------------------------------------------------
\ Matthias Fuchs \
\ esd electronic system design Gmbh \
\ Vahrenwalder Straße 205 \
\ D-30165 Hannover \
\ email: matthias.fuchs@esd-electronics.com \
\ phone: +49-511-37298-0 \
\ fax: +49-511-37298-68 \
--------------------------------------------------
Article: 31811Austin Franklin wrote: > <snip> > Others opined that it was the first semiconductor FIFO, which is what I > continued to refute. Any digital designs done since 1960 would be made from > semiconductors. Austin, you overestimate the IC ( or semiconductor ) capabilities in the "sixties". I got my MS-EE in 1957, so I remember. A few registers and counters were implemented with transistors, later ICs, but anything called "memory" was built with cores. And let's not split hairs. Yes, a flip-flop is a memory... The FIFO in 1971 was the first "smart memory", or "memory combined with logic", which had really not been practical with core memories. I think this discussion is getting a bit long in the tooth, but since I (innocently) stated it, here is my opinion. Peter AlfkeArticle: 31812
Brian_Sullivan wrote: > Whichever package you've chosen, those pins are not the dedicated > global pins. If the board is already laid out and you want to keep > the pins you've chosen, go to the Assign menu. Then choose Global > Project Logic Synthesis... In the bottom right hand of the window > will be the automatic global section. Turn those to off and the > design should fit. > > If those pins you chose were arbitrary, just remove the assignments > and MAX+PLUS II will put the signals on the dedicated pins for you > (assuming the auto global is turned on). > > I hope this helps. > Thanks! This was the solution of the problem. -- ... ................................................. ... . Name : Miika Pekkarinen ¤ ICQ : 45609012 . . E-Mail : miipekk@cc.jyu.fi ¤ WWW : www.ihme.org . ''' '''Article: 31813
hello world, I'm designing a board with a SpartanII. The FPGA should be configured using slave parallel mode (with a microcontroller), and I want to be able to do readback (also in slave parallel). Up to this point all is clear. But after configuration and while no readback is in progress, I want to use the pins D0...D7, _CS, _WRITE and BUSY as user I/Os. I understand the data sheet in the way that this should be possible: "These pins become user I/Os after configuration unless the Slave Parallel port is retained." But how to retain the slave parallel port, and how to _not_ retain? Should I change the mode pins after configuration to free D0...? Are the mode pins sampled after configuration too? (the data sheet says that M0,M1,M2 are sampled before configuration when _INIT goes high after clearing the configuration memory.) Or are D0...D7 user I/Os after configuration when _CS is not asserted? But how to use _CS as user I/O? I can't find any hints in the data sheet or appnotes. Can anyone help me? Greetings WernerArticle: 31814
Yea. $26K. Utku Ozcan wrote in message <3B15FCF1.350339EC@netas.com.tr>... >Anthony Ellis wrote: > >> Anyone know where I can get a VHDL bus interface model (functional only) >> for a PowerPC 603E. I need such for use in a test bench. >> Thanks Anthony > >Synopsys LMC software/hardware models is just right option for you. >For details please visit http://www.synopsys.com. > >Utku > >Article: 31815
Austin Franklin schrieb: > > > Interesting. > > So there are cases where the schematic is simpler than theVHDL. > > ... > > Peter Alfke > > ======================== > > Cases? Schematic is most ALWAYS simpler than any HDL (if done properly and > with the right tools)...but you really don't want get me going on that, now > do you? If you do, I'll be HAPPY to chime in ;-) Here we go. Schematic is IMHO just practical for simple designs, but when complexity rises, you are lost with schematics. Sure, it takes it time to get into VHDL (or Verilog) but it is not THAT hard. And once in, you will NEVER return to schematics, because HDL is much more powerful, easier to use and is a much different way of designing digital logic. -- MFG FalkArticle: 31816
Rick Collins schrieb: > [ statement about HDLs] > > So jump in and get to know HDLs. You may even like it once you learn the > flow. 100% ACK. -- MFG FalkArticle: 31817
Miika, Brian mentioned 2 options. One option moves the clock input to a dedicated clock input pin, where it can drive a chip-wide low-skew distribution network. This is the option that will help ensure that your design works. The other option tells the "compiler" that it's OK to route the clock on normal, high-skew interconnect. There are a lot of potential problems with this "solution". If this is the path you've taken, you need to convince yourself that the on-chip clock distribution skews match the *minimum* on-chip register-register path delays. This can be a painstaking tedious job, which needs to done over for every iteration of the design that is released to the rest of the world. This distinction between the two options needs to be recognized and understood: one is a solution and the other is potentially (at best) a "band-aid". -- Bob Elkind, eteam@aracnet.com Miika Pekkarinen wrote: > > Brian_Sullivan wrote: > > > Whichever package you've chosen, those pins are not the dedicated > > global pins. If the board is already laid out and you want to keep > > the pins you've chosen, go to the Assign menu. Then choose Global > > Project Logic Synthesis... In the bottom right hand of the window > > will be the automatic global section. Turn those to off and the > > design should fit. > > > > If those pins you chose were arbitrary, just remove the assignments > > and MAX+PLUS II will put the signals on the dedicated pins for you > > (assuming the auto global is turned on). > > > > I hope this helps. > > > > Thanks! > This was the solution of the problem. > > -- > ... ................................................. ... > . Name : Miika Pekkarinen ¤ ICQ : 45609012 . > . E-Mail : miipekk@cc.jyu.fi ¤ WWW : www.ihme.org . > ''' '''Article: 31818
Austin Franklin schrieb: > > > Actually, I don't have a dislike for HDLs, but for the tools! This is not a perfect world ;-) > How do you know? Do you go in and check with FPGA editor? You can do that. But a quick comparison can be made with the usage report (FFs, LUTs ...) > > What has happened is now that the parts are so much faster, just like the > x86 CPUs, one can get design implementations that are not very optimal, but > meet timing. The parts are also so much larger, so taking up more resources > using HDLs to implement a function, isn't such a big deal. HDL software isnt THAT bad. Sure, a pro can always get better results than a "stupid" compiler but for what efford?? Finetuning by hand is required only for lets say 10% of all designs. I think its like in software business. 90% of computation time is spent in 10% of the code. So optimize the 10%. > > > The only exception is when I need to use a unique architectural > > feature. Other than instantiation, this can be difficult to coax. But > > often there is no good reason not to use instantiation. Jep. > > > > So jump in and get to know HDLs. You may even like it once you learn the > > flow. > > Er, I have been using HDLs since they first came out...I know them quite > well, and have done probably hundreds of thousands of lines of ASIC, FPGA > and simulation code in HDL. That has nothing to do with the actual issues > that the tools have. What kind of HDL?? > > What I would like to see is the tool vendors provide a document that shows > how the constructs are disseminated. It should be deterministic, and the > designer needs to know, without having to play games, or worry between > revisions of the same tool, how the tools behave. The key is consistency. Thats a point. -- MFG FalkArticle: 31819
ruitenbe@cs.utwente.nl wrote in message news:<9fl93k$sp6$1@ares.cs.utwente.nl>... > if pulscnt[].q == buff[].q then > waveout = vcc; > pulscnt[].d = pulscnt[].q + 1; > zendloop[].d=zendloop[].q+1; > elsif pulscnt[].q == nieuw[].q then > waveout=gnd; > pulscnt[].d=0; > elsif zendloop[].q == 50 then > SA = sa0; > else > pulscnt[].d = pulscnt[].q+1; > end if; > > Both buff[].q and nieuw[].q have values assigned (variable) but I can't get a > zendloop[] to count, and I can't get waveout to be high, longer than 1 clock > cycle. > > Any help is greatly appreciated Let me repeat the problem so I understand correctly. You want to take puslcnt and increment.. When it reaches the value in buff, you want to set waveout. You want waveout to remain high until pulscnt reaches the value in nieuw. When you get 50 of these signals, you want to send the state machine to a different state. If all this is correct, the code would look something like this: if pulscnt[] == buff[] then waveout = vcc; pulscnt[] = pulscnt[] + 1; zendloop[] = zendloop[] + 1; elsif pulscnt[] == nieuw[] then waveout = gnd; pulscnt[] = 0; elsif zendloop == 50 then waveout = gnd; -- I assume gnd here, but put whatever value you want SA = sa0; else pulscnt[] = pulscnt[] + 1; waveout = waveout; end if; ---------------------- Basically, 2 things with the code. In AHDL, if a signal that was stated in a part of an if structure is not given a value in the other parts of the structure, gnd is the inferred value (except state machines which will remain in the present state). Thus the problem with waveout only being active for 1 clock cycle. And there might have been problems with zendloop reinitializing when you did not want it to. It also might be better to break up the if statement into 2 different if statements. the logic for the count enable on pulscnt[] can be reduced by putting it in its own if-then clause. I hope this helps. If I have misunderstood your application, please feel free to send me a waveform of what you want and I'll help out. BrianArticle: 31820
Peter Alfke wrote: > The device came in a 16-pin package. 4 Din, 4 Dout, clock and Busy on the input, > clock and Ready on the output. Could be cascaded ad infinitum. Ah! the good old days when you could count pins on ones fingers and toes. Also what ever happened to LOW COST chips like $25 not $250 or $2,500. Ben.Article: 31821
Austin Lesea wrote:
> I can't resist.
{ big snip }
In my case I was thinking of CPU's like 8080 Z80 386 586.
I for some reason I like to have chips in sizes no larger than
84 PLCC's. Could be that sockets are a factor - $1 vs $100.
What about the ROM cost and programing cost?
Ben.
Article: 31822ospyng@yahoo.com (spyng) wrote in message news:<b34a8c79.0106060548.6c71a149@posting.google.com>... > hi all, > > I need to designg a auto increment register in a fpga (virtexII) > for Arm to access the fpga internal memory. The register is suppost to be > use as a src_ptr for an indirect memory access. > > so if an control bit, say .. "auto increment" is set, any access to another register > the data_reg will increment the src_ptr. > > clk for arm is 35.7ns, clk for fpga is 8.9ns. > > I came out with a design but it is using gated clock, which I am not > very comfortable with. there must be some other way, auto increment should > be common?! > > anyone have any idea? or some link ... etc > > anyway here is what I come out with. > > for the src_ptr, a preload counter > preload is control by the (wr_n==0 and src_ptr_sel and fpga_sel) from arm. > value for preload is data from arm > > clock to the counter, + ve edge > a nand gate with (fpga_sel,data_reg_sel,rd_n,wr_n,auto_increment ) from arm. > if the skew between these signal is properly constraint, there should be > no glitch, > is should work right ? > > fpga_sel and data_reg_sel is decoded from the address send from arm. ( so more signel > to constraint) > > > any comment? > > thanks > spyng Hello, I just wanted to make you aware that Altera has a device with an embedded ARM processor and an FPGA, the Excalibur ARM. They have dedicated large blocks of RAM up to 3+Mbit in addition to the ESB RAMs already in the FPGA portion. The functionality you describe is already hardwired into the device and may make your life a little easier. But if you are set on using VirtexII and seperate ARM device then let me understand something. You want a counter that will load when certain conditions are met. Then you want to increment it only when another bit is set. But you only want to increment every 4 clock cycles of the 8.9 clock (I assume the 2 clocks are related and the reason t is not an integer multiple is due to rounding). Create a free running 2-bit counter (or 4 bit shift register that loops back on itself preloaded with bit 0 set). Decode a value (any value as long as it remains the same) and use that decode along with the signals from the ARM processor and the increment bit to enable the counter through the clock enable port in the DFF. Hope this helps. BrianArticle: 31823
> > > Interesting. > > > So there are cases where the schematic is simpler than theVHDL. > > > ... > > > Peter Alfke > > > ======================== > > > > Cases? Schematic is most ALWAYS simpler than any HDL (if done properly and > > with the right tools)...but you really don't want get me going on that, now > > do you? If you do, I'll be HAPPY to chime in ;-) > > Here we go. Schematic is IMHO just practical for simple designs, but > when complexity rises, you are lost with schematics. Absolutely untrue, if you know how to use the tool. In fact, one of the most complex and fastest CPUs ever made, and its support chips, were done in schematic, simply because HDL tools could not do the job. Sure, it takes it > time to get into VHDL (or Verilog) but it is not THAT hard. And once in, > you will NEVER return to schematics, because HDL is much more powerful, > easier to use and is a much different way of designing digital logic. That's wrong. I've been doing BOTH schematics and HDL for over a decade for ASIC and FPGA designs. I know HDLs and the associated tools quite well. HDL tools STILL can't give you what a schematic can, unless you use the HDL as a netlister. There certainly are circumstances where the compromises that HDLs pose don't interfere with the design criteria. There is nothing wrong, per se, with HDLs, it's just the right tool for the right job, and HDLs aren't always the right tool.Article: 31824
I can agree with Falk, but my interests may be special. I am creating tiny, very tight-knit designs that squeeze the last fractional nanosecond ( or best density ) out of a chip. I know the architecture, its possibilities and limitations, and I already see the one and only interconnect scheme that gives me my 1 GHz counter, or my 250 MHz FIFO controller, or my metastability test circuit... When I ask for help from VHDL and Verilog "experts", I get their generalized code that sacrifices performance. I want an HDL dialect subset that allows me to dictate connectivity to the last iota, but do it in an ASCII format that's easier to communicate and to integrate into larger designs. I am sure there is a solution, but I have not run into it. Of course I would have to sacrifice portability. But I happen not to work for Altera or an ASIC house :-) Peter Alfke =============================== Falk Brunner wrote: > Here we go. Schematic is IMHO just practical for simple designs, but > when complexity rises, you are lost with schematics. Sure, it takes it > time to get into VHDL (or Verilog) but it is not THAT hard. And once in, > you will NEVER return to schematics, because HDL is much more powerful, > easier to use and is a much different way of designing digital logic. > > -- > MFG > Falk
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z