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
NickNitro wrote: > Hi, > > Apologies if this isn't the best group, but there doesn't appear to be > a comp.arch.cpld group. > > I'm going to start learning about CPLDs to use them in my projects, > but the algorithm I've developed will require a few CPLDs working on > different parts of the algorithm in sequence. So part A of the > algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. Probably not the best direction. > They > are all complete guesses at the moment, as I know next to nothing > about PLDs in general, but I know that for my algorithm to run as fast > as required, I will require multiple PLDs. I'm choosing CPLDs as from > what I've read FPGAs can be a bit overbearing for a beginner due to > the amount of features/number of gates they have, You do not have to use all features on the first pass :) > also CPLDs have more predictable timing? On simple designs, yes. As multiple CPLDs get into the frame, it gets harder. > > So, I'm wondering just how difficult using multiple CPLDs on a custom > PCB actually is? I'm sure it's achievable, but I would like to know > how difficult this could be. The real fish-hook comes, when you find "Part B" really needed 9 devices! > Also, could any simulators be used to > simulate a complex design with multiple CPLDs on a PCB? Not easily. You _could_ have two designs, one that is partitioned into the smaller blocks, and another that is the whole system. The whole system one would simulate - but you may have spotted by now, that such a whole systemm design, is a FPGA design flow :) > Finally, could > anybody recommend any books for getting started in the CPLD world - > I'm unsure to use Verilog or VHDL at the moment? Download the development tools, and try some code in each. Search for come examples close to what you want to do. The tools can target BOTH cpld, and FPGA (& both languages), so you can actually get quite advanced in the design, before you commit to a PCB design. (or even a final device) There are also cross-over CPLDs like MAX II and MachXO, and also the FLASH FPGAs from Actel and Lattice to look into. Give a short list if what your design needs to do, and someone here might suggest a device family, and an expected speed range. -jgArticle: 123776
Hello all,
I am working on merging code coverage results in Verification
Navigator from TransEDA. I am encountering an error that I can't seem
to figure out a solution for.
Has anyone here ever used vnavigator?
Here's the problem. When attempting to merge multiple results
directories, I run the following:
# vnmerge -verbose on e3_results/vnavigator_results e2_results/
vnavigator_results e4_results/vnavigator_results -log_file
all_merge.log -save merged_results
Verification Navigator version 2004.06(Build VN406-0-00), Copyright
1994-2003 TransEDA Technology Ltd
Merging the following components:
Index Files: /home/osprey/users/XXXXXX/e3_results/
vnavigator_results/vnavigator.index
/home/osprey/users/XXXXXX/e2_results/
vnavigator_results/vnavigator.index
/home/osprey/users/XXXXXX/e4_results/
vnavigator_results/vnavigator.index
Merging into target directory: /home/osprey/users/XXXXXX/
merged_results
Error: vnmerge_history execution failed. Merge aborted.
Um. Okay. There is no documentation on the "vnmerge_history"
function in the documents. Running it on it's own appears to work
without error.
# vnmerge_history e2_results/vnavigator_results/vnavigator.history
e3_results/vnavigator_results/vnavigator.history e4_results/
vnavigator_results/vnavigator.history -log_file vnmerge_history.log -
verbose -save merged_results/vnavigator.history
Verification Navigator version 2004.06(Build VN406-0-00), Copyright
1994-2004 TransEDA Technology Ltd
Reading instances from history files...
Processing e2_results/vnavigator_results/vnavigator.history
Processing e3_results/vnavigator_results/vnavigator.history
Processing e4_results/vnavigator_results/vnavigator.history
Loading coverage from history files...
Processing e2_results/vnavigator_results/vnavigator.history
Processing e3_results/vnavigator_results/vnavigator.history
Processing e4_results/vnavigator_results/vnavigator.history
Merging instance coverage...
Processing instance t.XXXXXX
Processing instance t.XXXXXX
Processing instance t.XXXXXX
Processing instance t.XXXXXX
Processing instance t.XXXXXX
Processing instance t.XXXXXX
Processing instance t.XXXXXX
Processing instance t.XXXXXX
Viewing the log file:
# cat vnmerge_history.log
Date: Tue Sep 4 15:47:35 2007
3 files were merged into merged_results/vnavigator.history
e2_results/vnavigator_results/vnavigator.history
e3_results/vnavigator_results/vnavigator.history
e4_results/vnavigator_results/vnavigator.history
0 files were rejected because of errors
So what's the problem? Has anyone encountered this before? I have
been playing around with options and attempted to merge using the GUI
with the same error. With TranEDA out of business now, I'm running
out of options to determine a solution.
Thanks in advance.
Article: 123777On Sep 4, 1:42 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > John Larkin wrote: > > (snip) > > > Incredible, dangerous nonsense. Absolutely moronic. Quote: > > "Referencing the Top and Bottom of the Same Plane. Whenever a signal > > switches layers and references first the top and then the bottom of > > the same plane we must still ask the question, how does the return > > current get from the top to the bottom of the plane. Do to the "skin > > effect" the current cannot flow through the plane, it can only flow on > > the surface of the plane. > > This is some sort of joke, right? > > It would seem to me that it would go around the hole for the via. > At least it could do that. > > (snip) > > > Except in extreme situations, it's safe to assume that parallel planes > > in a multilayer pcb, bypassed with scattered caps, is an equipotential > > structure. It's that simple. > > With sufficient distributed capacitance, due to both the planes > themselves and bypass capacitors, I would agree. Note that a plane > still has capacitance even without another nearby plane. ??? The physics laws are different in your area ? thx, VasileArticle: 123778
On Sep 2, 4:43 pm, James Harris <james.harri...@googlemail.com> wrote: > Should have said that part of the design is a large crossbar switch. > It may be relevant to the number of gates and/or the design style. should have asked, what's the data rate thru the cross bar per port? There are sometimes cheaper alternatives to a cross bar, such as message switching.Article: 123779
John Larkin wrote: (snip) > Incredible, dangerous nonsense. Absolutely moronic. Quote: > "Referencing the Top and Bottom of the Same Plane. Whenever a signal > switches layers and references first the top and then the bottom of > the same plane we must still ask the question, how does the return > current get from the top to the bottom of the plane. Do to the "skin > effect" the current cannot flow through the plane, it can only flow on > the surface of the plane. > This is some sort of joke, right? It would seem to me that it would go around the hole for the via. At least it could do that. (snip) > Except in extreme situations, it's safe to assume that parallel planes > in a multilayer pcb, bypassed with scattered caps, is an equipotential > structure. It's that simple. With sufficient distributed capacitance, due to both the planes themselves and bypass capacitors, I would agree. Note that a plane still has capacitance even without another nearby plane. For a wide plane and a narrow wire, it is likely that the relative capacitance is fairly high. -- glenArticle: 123780
On Sep 4, 3:40 pm, vasile <picli...@gmail.com> wrote: > On Aug 30, 8:41 am, Gabor <ga...@alacron.com> wrote: > > > > > On Aug 30, 9:41 am, Gabor <ga...@alacron.com> wrote: > > > > On Aug 30, 4:59 am, Guru <ales.gor...@email.si> wrote: > > > > > Hi all, > > > > > We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB > > > > x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as > > > > possible the DDR termination presents a problem. Since the Spartan3E > > > > does not have DCI, termination on chip is not possible. This means > > > > that 44 termination resistors should be added and maybe a VTT power > > > > source. The other problem is that according to MIG we should connect > > > > DDR to two banks. > > > > > Any good suggestions? > > > > Is it possible to eliminate termination resistors? > > > > > Cheers, > > > > > Guru > > > > If you're only driving a single chip with very short lines you > > > can probably get away without termination on everything except > > > the clock. I would suggest using SSTL2_I instead of SSTL2_II > > > to avoid overdriving. Another approach is to just leave out > > > the series termination on these signals and just add the parallel > > > termination to Vtt. I've used the latter method with Virtex2 > > > and an SO-DIMM without DCI on the data lines and SSTL2_I drive. > > > A good argument for leaving out the series termination is any > > > net where the driving stub (from the S3 to the resistor) is > > > about the same length as the driven stub (from the resistor > > > to the memory). Here the terminator is of dubious value. > > > > It's probably best to simulate your transmission lines, > > > especially if you're planning to run the memory at its > > > maximum speed of 166 MHz / DDR333. My V2 design ran at > > > 133 MHz / DDR266. > > > > HTH, > > > Gabor > > > One other thought if your main interest is in reducing the > > board size. Often I find that using a x32 single-data-rate > > (143 MHz) memory can save space. If you're using a TSSOP-66 > > package for the DDR part, the 86-pin TSSOP for the x32 SDR > > part has the same footprint and runs from +3.3V with no > > requirements for VREF and DQS pins on the FPGA and no > > Vtt or 2.5V supply. > > How looks the Vref signal inside the DDR II ? Exactly what is good > for ? > > thx, > Vasile Not quite sure what you're asking here. The point I was trying to make is that the single-data-rate parts don't need to tie up FPGA pins with Vref and DCI. On Virtex 2 parts, you can have as many as 6 Vref pins in one bank. If you use SSTL2 signalling instead of LVTTL you lose the ability to use these pins as I/O. If you also decide to use DCI you lose an additional 2 pins per bank. The DDR parts also have more control pins (differential clock adds one pin, DQS adds one per 8 bits of interface). So if you can live with the data rates of the single- data-rate parts, you can avoid a lot of headaches and perhaps use only a small number of additional pins to double the data width. By the way, for SSTL2 you need Vref as a precision threshold reference at 1/2 Vddq, usually 1.25V or 1.3V depending on the speed for DDR I parts. LVTTL allows a wide threshold tolerance, usually 0.8 to 2.0v but generally won't work well at DDR bit rates.Article: 123781
James Harris wrote: > I'd like to try out some ideas and would appreciate some guidance. > Would a 200k-gate FPGA be enough for a simple or complex 8-bit CPU > design? I think that should be enough for a good sized CPU. Maybe for some of the support logic, also. (snip) > 1. What language would be suitable - VHDL or Verilog? Or are there > others? That is about equivalent to asking if you should use Ada or C for software development. Either will work in most cases, one likely suits you better. > 2. What description style would be appropriate? Or can I break the > design into modules, initially make each module with a high level > description and rewrite it at a lower level later as needed? As with software, the appropriate level of modularization is up to you. Both verilog and VHDL allow modules. With many you can mix VHDL and verilog modules in the same design (along with schematic capture and a few other languages). -- glenArticle: 123782
On 2007-09-02, Guru <ales.gorkic@email.si> wrote: > What about 8 bit DDR2? This way I can get away with only one FPGA bank > and layout to MIG rules. > Did anyone used it with MPMC2 (x8 is not supported by MCH_OPB_DDR2)? Double check that MPMC2 uses ODT. I'm not sure it does. Otherwise DDR2 is a big win if you are worried about signal integrity. If you've seen a DDR design go wrong, the DDR2 data sheets will make you say, "wow, that would have been handy!" about 100 times. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 123783
On Sep 4, 2:08 pm, NickNitro <NickHo...@googlemail.com> wrote: > Hi, > > Apologies if this isn't the best group, but there doesn't appear to be > a comp.arch.cpld group. > > I'm going to start learning about CPLDs to use them in my projects, > but the algorithm I've developed will require a few CPLDs working on > different parts of the algorithm in sequence. So part A of the > algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. They > are all complete guesses at the moment, as I know next to nothing > about PLDs in general, but I know that for my algorithm to run as fast > as required, I will require multiple PLDs. I'm choosing CPLDs as from > what I've read FPGAs can be a bit overbearing for a beginner due to > the amount of features/number of gates they have, also CPLDs have more > predictable timing? > As someone who started designing with TTL, then PALs and GALs, then CPLDs, then FPGAs, I would take issue with that reasoning. I find FPGA's much easier to use if the alternative means using multiple of any sort of part. Generally there is a big advantage to fitting a design in a single part. Partitioning the design was always the biggest part of the design process when I used the smaller parts. Fitting the design in a single part also frees you from reworking your PC board when you realize you needed another signal in one of the CPLD's, or you run out of macrocells or internal routing. Once you have made the decision to use a high-level language to design your logic, using an FPGA becomes actually simpler than the multiple CPLD approach. Also while CPLD's may have predictable timing, modern FPGA's have such fast internal timing that you generally can meet timing easily for nearly any design that runs in a CPLD. Even pin-to-pin timing can be fast in FPGA's nowadays. And if you look at the timing of the signals you route from one CPLD to another, and think of using only internal FPGA timing on those, you may find the design running considerably faster. Depending on your algorithm CPLD's can be bad for timing. For example if your equations end up with too many product terms you suddenly double the delay. You didn't mention the clock speeds you're shooting for, but those superfast CPLD's aren't so hot if you need to go through 2 macrocells or more between registers. Also think of all of the connections you don't need to make when your design fits in one part. O.K. you don't have all those extra points to scope on when you debug, but there are better tools for debugging in FPGA's that don't require physical access to the chip guts (see ChipScope on the Xilinx site or ispTracy from Lattice). > So, I'm wondering just how difficult using multiple CPLDs on a custom > PCB actually is? I'm sure it's achievable, but I would like to know > how difficult this could be. Also, could any simulators be used to > simulate a complex design with multiple CPLDs on a PCB? Finally, could > anybody recommend any books for getting started in the CPLD world - > I'm unsure to use Verilog or VHDL at the moment? > There are plenty of threads on the language selection. No need to start up another one here. Google for Verilog vs VHDL for some heated discussions. Also check out comp.lang.verilog and comp.lang.vhdl for lots of threads on books for newbies, etc. > Thanks for your time. > Nick. Good Luck, GaborArticle: 123784
Hi Jim, Thanks for taking the time out to reply. > > I'm going to start learning about CPLDs to use them in my projects, > > but the algorithm I've developed will require a few CPLDs working on > > different parts of the algorithm in sequence. So part A of the > > algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. > Probably not the best direction. May I ask why? > The real fish-hook comes, when you find "Part B" really needed 9 devices! But if everything is solidly designed before code is started, then this shouldn't happen? > Not easily. You _could_ have two designs, one that is partitioned > into the smaller blocks, and another that is the whole system. > The whole system one would simulate - but you may have spotted by > now, that such a whole systemm design, is a FPGA design flow :) If done correctly though wouldn't multiple CPLDs working on different parts of the algorithm perform better overall than a single FPGA? > Download the development tools, and try some code in each. > Search for come examples close to what you want to do. > The tools can target BOTH cpld, and FPGA (& both languages), > so you can actually get quite advanced in the design, before you commit > to a PCB design. (or even a final device) > > There are also cross-over CPLDs like MAX II and MachXO, and > also the FLASH FPGAs from Actel and Lattice to look into. Appreciated, I'll have a look. Thanks again, Nick.Article: 123785
On 3 Sep, 13:33, Andreas Ehliar <ehl...@lysator.liu.se> wrote: ... > I don't remember any exact reference now but I remember reading postings > on this group saying that it might be better to pipeline an FPGA > design more than you might think since hazard spikes propagating through > a long net might consume more power than the network itself. Something > to keep in mind at least. I haven't tried to verify this myself though. > Searching the group should yield some references which you might be > interested in evaluating before you start working on this. Simplistically, I'm thinking that each compute element (effectively each part of the ALU) would raise or lower an output-ready indicator just after its output lines had stabilised. When the next component has read the output of that compute element it would strobe an acknowledge line. The compute element would then reset its output- ready line and be free to take on another piece of work. I guess this is simple handshaking. I've tried a search for clockless CPU which is a good summary of what I have in mind. Some posts said others had thought of it but it would be almost impossible to test but I cannot see why. I tried a search for hazard spikes and got your post, above! The idea makes sense to me but then it is admittedly very simplistic. -- JamesArticle: 123786
On 4 Sep, 19:38, fpga_t...@yahoo.com wrote: ... > Isn't that a 7x7 crossbar with 10 bit data path , 3 bits of addressing > to specify a port? > total size would be 10*2*7=140 LUTs for crossbar port input mux tree. Quite possibly. > Much different problem than a 70x70 single bit data path with 7 bits > of addressing. > That problem requires 70*64=4,480 LUTs. Each output bit would only come from one of 7 inputs, yes, not one from 70. An output bit zero could only come from one of the input bits zero.Article: 123787
On 4 Sep, 20:55, fpga_t...@yahoo.com wrote: > On Sep 2, 4:43 pm, James Harris <james.harri...@googlemail.com> wrote: > > > Should have said that part of the design is a large crossbar switch. > > It may be relevant to the number of gates and/or the design style. > > should have asked, what's the data rate thru the cross bar per port? > > There are sometimes cheaper alternatives to a cross bar, such as > message switching. I think most alternatives are not non-blocking which is the main characteristic I want from the switching system. That said, the switching part of the idea is independent of other parts so the design of the switch should affect performance but not correctness.Article: 123788
James Harris wrote: > Simplistically, I'm thinking that each compute element (effectively > each part of the ALU) would raise or lower an output-ready indicator > just after its output lines had stabilised. When the next component > has read the output of that compute element it would strobe an > acknowledge line. The compute element would then reset its output- > ready line and be free to take on another piece of work. I guess this > is simple handshaking. Some keywords for searching are dual-rail signalling and Muller C gate. It sounds interesting, but I didn't tried it and some earlier postings in this newsgroup suggests that unclocked designs are not very well supported by FPGA synthesis tools, like Xilinx ISE and Altera Quartus, and they are more difficult to design. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 123789
On Tue, 04 Sep 2007 19:52:44 -0000, vasile <piclist9@gmail.com> wrote: >On Sep 4, 1:42 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> John Larkin wrote: >> >> (snip) >> >> > Incredible, dangerous nonsense. Absolutely moronic. Quote: >> > "Referencing the Top and Bottom of the Same Plane. Whenever a signal >> > switches layers and references first the top and then the bottom of >> > the same plane we must still ask the question, how does the return >> > current get from the top to the bottom of the plane. Do to the "skin >> > effect" the current cannot flow through the plane, it can only flow on >> > the surface of the plane. >> > This is some sort of joke, right? >> >> It would seem to me that it would go around the hole for the via. >> At least it could do that. >> >> (snip) >> >> > Except in extreme situations, it's safe to assume that parallel planes >> > in a multilayer pcb, bypassed with scattered caps, is an equipotential >> > structure. It's that simple. >> >> With sufficient distributed capacitance, due to both the planes >> themselves and bypass capacitors, I would agree. Note that a plane >> still has capacitance even without another nearby plane. > >??? The physics laws are different in your area ? >thx, >Vasile "My area" is the universe, and everything has capacitance to the universe. Where do you live? JohnArticle: 123790
> Gabor wrote: <snip> Hi Gabor, The only thing is is that my algorithm has to work on 2^17 bits, all in one go, so it would have to work on one group then another group then another etc... until it has worked on all groups of bits. However, with the constant input output to the fpga I thought it would be a major delay, so I (naively) assumed using multiple CPLDs would be best because they would have the same wire delay as that as an fpga. >>You didn't mention the clock speeds you're shooting for, but those superfast CPLD's aren't so hot if you need to go through 2 macrocells or more between registers. Well to be honest I don't have a clue. But I again naively assumed that having more than one pld working on the problem would be better than one pld working on the problem. >>There are plenty of threads on the language selection. No need to start up another one here. Apologies, I wasn't intending to create a flame war, but instead hoping for suggestions on a book or two that would give me the pros and cons of the languages to help me make a decision. >>Good Luck, I'm needing a bit more than luck I think for something as ambitious this - thanks anyway. Nick.Article: 123791
NickNitro wrote: > Hi Jim, > > Thanks for taking the time out to reply. > >>>I'm going to start learning about CPLDs to use them in my projects, >>>but the algorithm I've developed will require a few CPLDs working on >>>different parts of the algorithm in sequence. So part A of the >>>algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. >> >>Probably not the best direction. > > > May I ask why? My subsequent comments explained why. > > >>The real fish-hook comes, when you find "Part B" really needed 9 devices! > > > But if everything is solidly designed before code is started, then > this shouldn't happen? Perhaps in theory, but 'algortihm development' is a very fluid thing, and a good designer allows for late changes. > >>Not easily. You _could_ have two designs, one that is partitioned >>into the smaller blocks, and another that is the whole system. >>The whole system one would simulate - but you may have spotted by >>now, that such a whole systemm design, is a FPGA design flow :) > > > If done correctly though wouldn't multiple CPLDs working on different > parts of the algorithm perform better overall than a single FPGA? That would depend on the design details, which is why you should get the tools, and actually implement the design before starting the PCB. Device retargeting is not difficult. -jgArticle: 123792
On Sep 4, 3:28 pm, James Harris <james.harri...@googlemail.com> wrote: > On 4 Sep, 19:38, fpga_t...@yahoo.com wrote: > ... > > > Isn't that a 7x7 crossbar with 10 bit data path , 3 bits of addressing > > to specify a port? > > total size would be 10*2*7=140 LUTs for crossbar port input mux tree. > > Quite possibly. > > > Much different problem than a 70x70 single bit data path with 7 bits > > of addressing. > > That problem requires 70*64=4,480 LUTs. > > Each output bit would only come from one of 7 inputs, yes, not one > from 70. An output bit zero could only come from one of the input bits > zero. with 7 ports total, ignoring loopback, there are 6 other sources. You can pack a 3:1 mux into the LUT and carry logic, with some tricks ... reference Carl Brannen's posts in this forum back around Dec 2001. I gave Carl's post to Guerric who took the paper and did 3:1 muxes for our d.net RC5 fpga core to cut the barrel shifter depth and area - not pretty, but dense and fast with constrained routing. The cpu side of the project sounds more fun ... :)Article: 123793
>> The real fish-hook comes, when you find "Part B" really needed 9 devices! > >But if everything is solidly designed before code is started, then >this shouldn't happen? Don't you ever get a new idea after a design has been running for a while? > If done correctly though wouldn't multiple CPLDs working on different > parts of the algorithm perform better overall than a single FPGA? Why would you think that way? Getting on/off chip is usually slow. If your FPGA is big enough to hold the whole design, I'd expect it to be faster. CPLDs generally have wide inputs relative to LUTs in FPGAs. There are probably some designs that will be faster on CPLDs because they take advantage of that. Another potential advantage of FPGAs is that you can get prototype boards that might be good enough for your problem. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123794
On Sep 4, 3:30 pm, James Harris <james.harri...@googlemail.com> wrote: > I think most alternatives are not non-blocking which is the main > characteristic I want from the switching system. That said, the > switching part of the idea is independent of other parts so the design > of the switch should affect performance but not correctness. The reason I asked about data rate, is another dense architecture is a 7x TDM using one 10 bit wide mux tree to sample all inputs as a front end, and backend it into 7 SRL's with the tap set to the desired channel, with the SRL's FF clocked at 1/7th the data clock. Very small crossbar design, but the external frequency can not be faster the 1/7th the core TDM rate if sync, or would need over clocking if async. Fits into about 15-20 slices with some handy work. Input mux is 10 slices, another 3-1/2 for 7 SRL lanes, and a few more for timing logic. The SRL cycle timing will limit your clock rate.Article: 123795
Nick, you are much better off doing this design inside one FPGA, even if you have to operate sequentially on 128000 bits (is that what you really meant with 2^17 bits?) I would also use one of the many existing evaluation boards, which eliminates a lot of work, time, money, and risk. I would focus on one of the Xilinx Spartan evaluation boards, and go to a Virtex-4 evaluation board only if the design really mushrooms (which I doubt) I would first sketch out the basic design on paper, to easily see the speed bottlnecks, but that may just be my style... Peter Alfke, Xilinx ============================Article: 123796
On 4 Sep, 23:16, fpga_t...@yahoo.com wrote: ... > The cpu side of the project sounds more fun ... :) It's great that you like the idea. In fact the crossbar is intended to be the main way values get from one compute element to another so it is really part of the CPU. I have no idea how I am going to control operations yet - i.e. select what operations happen and in what order, and where the results are to be stored (without the cost of passing the control info through the switch). Sure, it should be fun to work it through.Article: 123797
On Sep 4, 4:37 pm, fpga_t...@yahoo.com wrote: > On Sep 4, 3:30 pm, James Harris <james.harri...@googlemail.com> wrote: > > > I think most alternatives are not non-blocking which is the main > > characteristic I want from the switching system. That said, the > > switching part of the idea is independent of other parts so the design > > of the switch should affect performance but not correctness. > > The reason I asked about data rate, is another dense architecture is > a 7x TDM using one 10 bit wide mux tree to sample all inputs as a > front end, and backend it into 7 SRL's with the tap set to the desired > channel, with the SRL's FF clocked at 1/7th the data clock. Very > small crossbar design, but the external frequency can not be faster > the 1/7th the core TDM rate if sync, or would need over clocking if > async. Fits into about 15-20 slices with some handy work. Input mux is > 10 slices, another 3-1/2 for 7 SRL lanes, and a few more for timing > logic. The SRL cycle timing will limit your clock rate. hmm ... forgot to add up the FF's required ... 70+ of FF's ... so a little over 40 slices :(Article: 123798
On Tue, 04 Sep 2007 11:08:49 -0700, NickNitro <NickHolby@googlemail.com> wrote: >Hi, > >Apologies if this isn't the best group, but there doesn't appear to be >a comp.arch.cpld group. > >I'm going to start learning about CPLDs to use them in my projects, >but the algorithm I've developed will require a few CPLDs working on >different parts of the algorithm in sequence. So part A of the >algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. They >are all complete guesses at the moment, as I know next to nothing >about PLDs in general, but I know that for my algorithm to run as fast >as required, I will require multiple PLDs. I'm choosing CPLDs as from >what I've read FPGAs can be a bit overbearing for a beginner due to >the amount of features/number of gates they have, also CPLDs have more >predictable timing? > >So, I'm wondering just how difficult using multiple CPLDs on a custom >PCB actually is? I'm sure it's achievable, but I would like to know >how difficult this could be. Also, could any simulators be used to >simulate a complex design with multiple CPLDs on a PCB? Finally, could >anybody recommend any books for getting started in the CPLD world - >I'm unsure to use Verilog or VHDL at the moment? > >Thanks for your time. >Nick. I'd recommend using an FPGA. The CPLD pins/interconnects can be deadly, not to mention slow. And as you mention, simulation of the entire design is a lot easier if it's all in one chip. JohnArticle: 123799
Hi all, >>Perhaps in theory, but 'algortihm development' is a very fluid thing, and a good designer allows for late changes. Well I don't think I've mentioned just how far the algorithm is through development, although is it completely designed and has been finalised by many people and all have signed it off. It has been designed down to the bit level and has been tested in a software environment with no flaws (strong words, but every possible scenario has been tested through brute forcing, so nothing has been missed); so I can safely say the algorithm being altered at this stage won't happen. >>Device retargeting is not difficult. I've done what you've suggested and had a look at the Xilinx web pack and if I've done it correctly, device retargeting seems to be just be selecting a different device from the list? Or am I greatly oversimplifying to what I imagine? >>Don't you ever get a new idea after a design has been running for a while? Very much, although as above, the algorithm is set in concrete. >>Why would you think that way? Getting on/off chip is usually slow. Naivety. ;) I'm coming from a software background, so unfortunately I'm relying on software knowledge, where more cores==better performance. >>CPLDs generally have wide inputs relative to LUTs in FPGAs. There are probably some designs that will be faster on CPLDs because they take advantage of that. I'm afraid I don't have a clue what 'wide inputs' are, but I'll take your word at it. ;) >>even if you have to operate sequentially on 128000 bits Yes, that's correct. >>I would also use one of the many existing evaluation boards, which eliminates a lot of work, time, money, and risk. Thing is, once it's working fine in the FPGA/evaluation board environment, I'll still need to move the chip to a custom PCB so it has the correct peripherals? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Speed is extremley important to this problem, I'm not too worried about the difficulty of this - just the final result; since ideally execution of the algorithm cannot take more than 15-20 milliseconds. I hope you don't think I'm being completely ignorant and rude asking this, nor do I want you to think that I don't appreciate your advice - although I can't help but think something like the following would be faster - I'm stuggling to shake off my software thinking: http://img529.imageshack.us/img529/9474/cpldlayoutus9.jpg Where 32 bits would be passed from a 'CPLD Memory Manager' to a 'CPLD Parallel Algorithm', and while that was working, another 32 bits would be passed from the same 'CPLD Memory Manager' to the next 'CPLD Parallel Algorithm', etc... and each 'CPLD Parallel Algorithm' when complete would check that the other 'CPLD Memory Manager' was available to take data and if so pass it to the memory manager, and then asking the first memory manager for some more data. Again, I apologise for sounding like a broken record. I'd appreciate your thoughts for the pros and cons for something like this. Thanks, Nick.
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