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
On 2008-10-16, Jim Granville <no.spam@designtools.maps.co.nz> wrote: > A nice small device for this, would be the new Serial SPI SRAM ? > http://www.onsemi.com/PowerSolutions/parametrics.do?id=2207 > SO8 or tssop8. This kind of device could be rather nice in some situations, thanks for mentioning it. It was fairly affordable on digi-key as well although not extremely cheap. > Perhaps add a SPI flash memory for the tiles > (quite large flash comes now in SO8, so I'd load one up with thousands > of next-tiles, and shift the random-tile decisons to the > flash-generation code :) - keeps the CPLD simpler... Nice idea. Although I must admit that my current solution doesn't really use any sort of tiles at all, just fully white or fully black (large) pixels. > all that assumes you stay in macrocell CPLDs, and do not move to > a Lattice MachXO type device. Exactly, this isn't very challenging in such a device, especially the ones with built in block rams. I've looked into the MachXO devices a little bit (I supervised a final year project which used such a device) and they seem like rather nice devices. If you are used to optimizing CPLD designs for the limitations of a traditional CPLD, the MachXO is luxuriously large... :) /AEArticle: 135801
Andreas Ehliar wrote: > > The purpose of this post is to try to get a discussion going > on various design tricks for severely limited devices like CPLDs. > On that note I'll pose the following challenges to the group: > > Challenge 1 - Tetris in as few CPLDs as possible > Challenge 2 - A digital watch with as few CPLDs as possible Put a simple soft core CPU in a xc95 and add some ROM/RAM, then a single CPLD should be enough.Article: 135802
Andreas Ehliar wrote: > How would you design a Tetris game if you only had CPLDs > available? How many CPLDs would you use and of what kind? The question doesn't make sense. I would use a EPM2210/G with 2,210 LEs and could install Nios on it, so all I need is one CPLD. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 135803
Andreas Ehliar wrote: > Challenge 2 - A digital watch with as few CPLDs as possible > ----------------------------------------------------------- > > This is an easier problem which should require fewer or smaller CPLDs > than the previous challenge. > > Requirements: > * Time should be showed in HH:MM:SS format (preferably 24h format) > * It should be possible to set an alarm (HH:MM precision is good enough) > * Stop watch functionality in MM:SS:T (That is, up to 59 minutes, 59 > seconds and 9 tenths of a second.) Why stop at :T, push the students a little :) ask for :TT - easy at 50Hz AC, a little harder at 60Hz and 32.768KHz - or even :TTT, and make a precision sports timer, with optical gates. Pass that to the Physics teachers and sports teams... > * There should be a user interface of some kind (it should be possible to > change the time that is) > * The time, alarm, and stop watch functionality shall work independently. > (You don't want your watch to stop working just because you are setting > your alarm or using the stop watch.) No mention of leading zero suppression ? > > What kind of display would you use here? (7 segment LEDs? LCD?, etc?) MUX'd or Non MUX'd ? LCDs need a XOR backplane, and they also have MUX choices too. > What kind of input? (Plain buttons or something different?) This opens up a large range of complexity/user-friendly trade offs: Up/Dn buttons are more friendly, but make more complex counters. Rotary encoders are even nicer, and a rate-sensistive rotary encoder nicer still. > What clock frequency do you need? 50Hz, 60Hz and 32.768KHz are the common ones.... > > This is a rather nice problem which will allow you to think about the > best way to do resource sharing in a CPLD. > > As a baseline, the students I have supervised who do this kind of project > end up with about 3 or 4 CPLDs. (Either XC9572 or XC95108.) They usually > don't bother with any kind of resource sharing though... You could get them to code direct 7 segment counters, for a non-mux display. Nice to show there are non Bin/bcd counters possible too... > Personally, I have a relatively small solution to this, but there are still > a few tricks I haven't used. In my solution I'm using a 7 segment LED driver > circuit with built in NBCD decoder (the 9368), so if you want to compare > your solution to mine you might want to output NBCD coded numbers out of your > CPLD. Surely the 9368 should be part of the CPLD ? -jgArticle: 135804
Andreas Ehliar wrote: > The purpose of this post is to try to get a discussion going > on various design tricks for severely limited devices like CPLDs. > On that note I'll pose the following challenges to the group: > > > > Challenge 1 - Tetris in as few CPLDs as possible > ------------------------------------------------ > > How would you design a Tetris game if you only had CPLDs > available? How many CPLDs would you use and of what kind? > > Would you need any other kind of circuits to implement an > efficient solution? (External SRAMs or EPROMs for example?) You need to define the Pixels and tile-sets. A nice small device for this, would be the new Serial SPI SRAM ? http://www.onsemi.com/PowerSolutions/parametrics.do?id=2207 SO8 or tssop8. Perhaps add a SPI flash memory for the tiles (quite large flash comes now in SO8, so I'd load one up with thousands of next-tiles, and shift the random-tile decisons to the flash-generation code :) - keeps the CPLD simpler... all that assumes you stay in macrocell CPLDs, and do not move to a Lattice MachXO type device. > > What kind of display would you use? (TV, Oscilloscope, Led matrix, etc?) Depends on the desired resolution. LED matrix is going to be a bit coarse. TV is the most widely available. (PAL or NTSC) > What kind of input device would you use? (Plain buttons or perhaps a > more advanced input device like a NES joypad?) Rotary encoder perhaps ? -jgArticle: 135805
On 15 Oct, 15:33, in...@rayed.de wrote: > On 14 Okt., 15:57, Leon <leon...@btinternet.com> wrote: > > > > > > > On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote: > > > > Bob wrote about XMOS: > > > > > They seem far too fixated on doing everything in software, things l= ike > > > > ethernet where there is no point shoveling bytes in software if > > > > hardware can take care of it. > > > Leon wrote: > > > > They are supplying free libraries for all the usual peripheral > > > > functions. Doing stuff like that in software is much cheaper than > > > > using hardware, and easier in many ways. > > > > Been there, done that, and it's not cheaper or easier when you > > > consider the overall system cost impact, not just the "benefit" of > > > leaving out the hardware block. =A0That was the path Scenix/Ubicom we= nt > > > down, calling it "virtual peripherals", and it was not very > > > successful. =A0Ubicom has since added hardware for Ethernet, USB, > > > etc. to their most recent parts. =A0The reality is that a hardware > > > Ethernet MAC costs less than the total system cost impact of the > > > software alternative. > > > > Eric > > > Not if you have four 400 MIPS cores on the chip, each with 64 bits of > > I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32 > > threads per core, with switching between threads in one clock. If the > > software is free, it is a very cost-effective solution, especially as > > the chips will be very cheap. > > XMOS found a way to make their chips so cheap, that they can do > everything cheaper in software than all others in hardware? > Why don't they sell this revolutionary technology to semiconductor / > FPGA companies then? > They just wouldn't tell anyone about it and the same big Market would > use it without knowing, =A0but at lower prices.- Hide quoted text - > > - Show quoted text - With chips anticipated to sell for as little as $1 each, and replacing FPGAs and DSPs in a lot of applications, I expect that the much larger established companies will be getting worried. XMOS already has several design wins, although the chips are not yet in full production. I've just heard that free samples of the BGA512 chip and the newer BGA144 chip will soon be available via the XMOS web site. The latter is in an 11x11 mm package, and is identical to the larger device, apart from only having the I/O from two cores brought out. It should be possible to put it on a low-cost 4-layer board, which is something I'll be doing. LeonArticle: 135806
On 15 Oct, 20:28, Anton Erasmus <nob...@spam.prevent.net> wrote: > On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter > > > > > > <p...@pcserviceselectronics.co.uk> wrote: > >In article > > =A0<3d4b6f41-b742-405d-87bd-47e2fb75a...@8g2000hse.googlegroups.com>, > >leon...@btinternet.com says... > >> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote: > >> > Bob wrote about XMOS: > > >> > > They seem far too fixated on doing everything in software, things = like > >> > > ethernet where there is no point shoveling bytes in software if > >> > > hardware can take care of it. > >> > Leon wrote: > >> > > They are supplying free libraries for all the usual peripheral > >> > > functions. Doing stuff like that in software is much cheaper than > >> > > using hardware, and easier in many ways. > > >> > Been there, done that, and it's not cheaper or easier when you > >> > consider the overall system cost impact, not just the "benefit" of > >> > leaving out the hardware block. =A0That was the path Scenix/Ubicom w= ent > >> > down, calling it "virtual peripherals", and it was not very > >> > successful. =A0Ubicom has since added hardware for Ethernet, USB, > >> > etc. to their most recent parts. =A0The reality is that a hardware > >> > Ethernet MAC costs less than the total system cost impact of the > >> > software alternative. > > >> > Eric > > >> Not if you have four 400 MIPS cores on the chip, each with 64 bits of > >> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32 > >> threads per core, with switching between threads in one clock. If the > >> software is free, it is a very cost-effective solution, especially as > >> the chips will be very cheap. > > >The PC market solution to determinisity - > > > =A0 =A0"If in doubt put bigger processor(s) and > > =A0 =A0 lots more memory to solve the 'problem'" > > >Having seen how easily screwed even software UARTs can get, and > >when something goes wrong all other activity is screwed. > > >The PC example is dodgy CD inserted, nothing else can work until > >the upto 30 seconds of lockout. Lots of other examples exist. > > >This sort of software emulation of hardware ONLY is useful for > >cheap and nasty commodity products that assume that unusability > >is always solved by a reset (for some products that means host PC > >AS WELL!). > > >This means for the VAST majority of *my* applications it is useless. > > I fully agree with this. Software is flexible and easier to correct > than hardware. Unfortunantely this has lead to the current thinking > that we can ship the product with known issues, since "We can always > fix it later". In most cases these fixes never happen. I would prefer > more peripherals in hardware, not less. TCP/IP stack in hardware, USB > stack in hardware etc. Something like IEEE-1394 is much more reliable > than USB, since all the enumeration etc is handled by the hardware. > With the right hardware support, which can be a few gates, software > can often be made much simpler, more robust and faster. A simple thing > like an atomic increment or decrement can be quite complex to > implement in software. In hardware it is trivial. In my experience > from porting code written for old hardware, to new hardware. > Calculation tasks are much faster on modern hardware. Moving data > around between buffers, and peripherals is only a little bit faster if > at all. Simple things like hardware that provides the amount of space > available in a FIFO in a register in stead of just a FIFO has space > flag, can easily make the moving of data easily 5x faster. > > Regards > =A0 Anton Erasmus- Hide quoted text - > > - Show quoted text - However, XMOS will be supplying fully tested and characterised "plug- in" software modules, which will get round the problems you mention. The XC language makes this very straightforward. LeonArticle: 135807
Andreas Ehliar wrote: > On 2008-10-16, Herbert Kleebauer <klee@unibwm.de> wrote: > > Put a simple soft core CPU in a xc95 and add some ROM/RAM, then > > a single CPLD should be enough. > > That is probably the easiest solution. A colleague and I have > However, what about if you would like to avoid an SRAM and EPROM, > what kind of techniques would you use in that case? I would use a FPGA instead of CPLD. With a xc3s1200e you can use 32 kbyte internal program/data memory an then have all the IO pins available for other purpose and with a simple CPU you also have nearly all the logic in the FPGA available for additional hardware. Here a CPU which uses 72 of 17344 Slice Flip Flops and 142 of 17344 4 input LUT's of xc3s1200e-4fg400. ftp://137.193.64.130/pub/mproz/mproz3_e.pdfArticle: 135808
On Wed, 15 Oct 2008 16:55:48 -0700, Mike Treseler <mtreseler@gmail.com> wrote: >Jan wrote: > > >> I use the free WebPack 10.1 from Xilinx and my target is a Spartan3. > >You will need one the non-free oem modelsim software to do simulation: >http://www.xilinx.com/ise/optional_prod/mxe.htm >The waveform simulator was just a toy anyway. >Modelsim is a separate program >and has its own tutorials. Actually the free ISE Simulator (ISIM, installed as part of Webpack) is coming along nicely as a VHDL simulator. (I haven't tried it as a waveform sim; you are probably right there). On the positive side, it's cross-language (if you avoid the bugs) and cross-platform, running on Linux unlike any reasonably priced VHDL offering from Modelsim. Plus the SmartModels are built in, not an extra cost option. In Webpack it has limited capacity of course (to 15000 lines of VHDL code) but that's enough for many behavioural simulations that don't involve something like an EDK project. On the other side... It still has bugs, but many of these are slated to be fixed in ISE 11.1. Xilinx support people are actively trying to make it better. Oddly enough, though Smartmodels are built in, EDK simulations are not supported. (Possibly because of the horrendous bugs in ISE's handling of VHDL libraries, which are supposed to be fixed in 11.1) The full version would be necessary for EDK sims because of capacity restraints anyway. It doesn't have the quality of Modelsim; it's not as stable for example; you often have to "cleanup project files" and "rerun all" because it has problems correctly handling file dependencies. It's not as reliable a reference for language lawyers (though it caught one valid restriction on integer range that Modelsim was permissive to let through.) Modelsim wasn't wrong in that case; a minimum range is guaranteed for integer, but implementations are allowed to offer more than that. But I wouldn't discourage an impoverished student from trying to use it. - BrianArticle: 135809
> I'm looking for a 32-bit CPU model written in C or Java or Python or > any high-level language that can be supported by gcc. How accurate does the model need to be? There are lots of CPU simulators that come as part of GDB. Cheers, JonArticle: 135810
John_H wrote: > There are two coupled LUTs for each dual-port distributed memory. The > normal address (A input) is used for the write (D input) along with the > control (WE). The Single Port Output (SPO output) is the same as you'd > have with distributed single port memories where the write address also > controls the single port read so you can perform a read-modify-write > with an async read to the clock edge where the data is taken in. The > other LUT has a separate Dual Port Read Address (DPRA input) which gives > you an async read on the Dual Port Output port (DPO output). > > The LUTs are normally only registered in the sense that a write moves > the data into the memory array and can then be accessed asynchronously. > The option in the Core IP Generator is probably to add the registers > that are directly adjacent to the SPO and DPO LUT outputs within the > slice to be used allowing a very fast clock-to-output time without > waiting for the address propagation for the async lookup. The > registered operation is another clock of pipeline and should be treated > conceptually just like adding the registers manually yourself. > - John_H That explains it all, thank you very much! Regards JanArticle: 135811
if falling_edge(clock2) then out2 <= data2; end if; if clock2='0' then out1 <= 'Z'; elsif falling_edge(clock1) then out1 <= data1; end if; (This is just a sample VHDL) Clock2 is used both as a GCK and as a signal. ISE (10.1) complains on Spartan 2. I've tried replacing clock2 with clock2a: signal clock2a : STD_LOGIC; component ibufg port ( O : out STD_LOGIC; I : in STD_LOGIC); end component; attribute box_type : string; attribute box_type of ibufg : component is "black_box"; temporary : ibufg port map (I => clock2, O => clock2a); >From the manual: "The IBUFG can be routed to your choice of logic to allow the use of the dedicated clock pins for general logic." Am I using it the correct way? I've also tried variations of buffer_type, no luck either. attribute buffer_type: string; attribute buffer_type of clock2: signal is "bufgp"; Even if I get it to work on this small example, ISE always complains on the complete project. Currently, I connect clock two 2 pins, GCK and a IOB, but this can probably be avoided. How?Article: 135812
On 16 oct, 06:40, Leon <leon...@btinternet.com> wrote: > On 15 Oct, 20:28, Anton Erasmus <nob...@spam.prevent.net> wrote: > > > > > On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter > > > <p...@pcserviceselectronics.co.uk> wrote: > > >In article > > > =A0<3d4b6f41-b742-405d-87bd-47e2fb75a...@8g2000hse.googlegroups.com>, > > >leon...@btinternet.com says... > > >> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote: > > >> > Bob wrote about XMOS: > > > >> > > They seem far too fixated on doing everything in software, thing= s like > > >> > > ethernet where there is no point shoveling bytes in software if > > >> > > hardware can take care of it. > > >> > Leon wrote: > > >> > > They are supplying free libraries for all the usual peripheral > > >> > > functions. Doing stuff like that in software is much cheaper tha= n > > >> > > using hardware, and easier in many ways. > > > >> > Been there, done that, and it's not cheaper or easier when you > > >> > consider the overall system cost impact, not just the "benefit" of > > >> > leaving out the hardware block. =A0That was the path Scenix/Ubicom= went > > >> > down, calling it "virtual peripherals", and it was not very > > >> > successful. =A0Ubicom has since added hardware for Ethernet, USB, > > >> > etc. to their most recent parts. =A0The reality is that a hardware > > >> > Ethernet MAC costs less than the total system cost impact of the > > >> > software alternative. > > > >> > Eric > > > >> Not if you have four 400 MIPS cores on the chip, each with 64 bits o= f > > >> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32 > > >> threads per core, with switching between threads in one clock. If th= e > > >> software is free, it is a very cost-effective solution, especially a= s > > >> the chips will be very cheap. > > > >The PC market solution to determinisity - > > > > =A0 =A0"If in doubt put bigger processor(s) and > > > =A0 =A0 lots more memory to solve the 'problem'" > > > >Having seen how easily screwed even software UARTs can get, and > > >when something goes wrong all other activity is screwed. > > > >The PC example is dodgy CD inserted, nothing else can work until > > >the upto 30 seconds of lockout. Lots of other examples exist. > > > >This sort of software emulation of hardware ONLY is useful for > > >cheap and nasty commodity products that assume that unusability > > >is always solved by a reset (for some products that means host PC > > >AS WELL!). > > > >This means for the VAST majority of *my* applications it is useless. > > > I fully agree with this. Software is flexible and easier to correct > > than hardware. Unfortunantely this has lead to the current thinking > > that we can ship the product with known issues, since "We can always > > fix it later". In most cases these fixes never happen. I would prefer > > more peripherals in hardware, not less. TCP/IP stack in hardware, USB > > stack in hardware etc. Something like IEEE-1394 is much more reliable > > than USB, since all the enumeration etc is handled by the hardware. > > With the right hardware support, which can be a few gates, software > > can often be made much simpler, more robust and faster. A simple thing > > like an atomic increment or decrement can be quite complex to > > implement in software. In hardware it is trivial. In my experience > > from porting code written for old hardware, to new hardware. > > Calculation tasks are much faster on modern hardware. Moving data > > around between buffers, and peripherals is only a little bit faster if > > at all. Simple things like hardware that provides the amount of space > > available in a FIFO in a register in stead of just a FIFO has space > > flag, can easily make the moving of data easily 5x faster. > > > Regards > > =A0 Anton Erasmus- Hide quoted text - > > > - Show quoted text - > > However, XMOS will be supplying fully tested and characterised "plug- > in" software modules, which will get round the problems you mention. > The XC language makes this very straightforward. > > Leon Seriously, how much are they paying you? To be fair, the XMOS seems like a promising device, I might consider using it someday, but it still hasn't been widely tested in real designs. How many MACs can it perform? Do you have benchmarks for FFTs, IIR filtering, FIR Filtering? What if you want to interface it to a DDR-II SDRAM module? Best regards BenjaminArticle: 135813
You probably don't want what you are describing, so please explain why you need that particular construct. Further, what you are describing cannot be constructed from logic components, so please explain how you expect that to be implemented in your FPGA. - Nathan On Oct 16, 7:03=A0am, aleksa <aleks...@gmail.com> wrote: > if falling_edge(clock2) then > =A0 =A0 =A0 =A0 out2 <=3D data2; > end if; > > if clock2=3D'0' then out1 <=3D 'Z'; > elsif falling_edge(clock1) then out1 <=3D data1; > end if; > > (This is just a sample VHDL) > > Clock2 is used both as a GCK and as a signal. > > ISE (10.1) complains on Spartan 2. > > I've tried replacing clock2 with clock2a: > =A0 =A0 =A0 =A0 signal clock2a : STD_LOGIC; > > =A0 =A0 =A0 =A0 component ibufg port ( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 O : out STD_LOGIC; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I : in =A0STD_LOGIC); > =A0 =A0 =A0 =A0 end component; > > =A0 =A0 =A0 =A0 attribute box_type : string; > =A0 =A0 =A0 =A0 attribute box_type of ibufg : component is "black_box"; > > =A0 =A0 =A0 =A0 temporary : ibufg port map (I =3D> clock2, O =3D> clock2a= ); > > From the manual: "The IBUFG can be routed to your choice of logic > to allow the use of the dedicated clock pins for general logic." > Am I using it the correct way? > > I've also tried variations of buffer_type, no luck either. > =A0 =A0 =A0 =A0 attribute buffer_type: string; > =A0 =A0 =A0 =A0 attribute buffer_type of clock2: signal is "bufgp"; > > Even if I get it to work on this small example, ISE always > complains on the complete project. > > Currently, I connect clock two 2 pins, GCK and a IOB, but this > can probably be avoided. How?Article: 135814
I've read that it's possible to program an SPI PROM via JTAG through the FPGA (Indirect SPI programming) but I can't find anything on how to get Impact to do this. Does anyone know how this is done please? TIA. Rog.Article: 135815
On Oct 16, 8:24=A0pm, "Roger" <rogerwil...@hotmail.com> wrote: > I've read that it's possible to program an SPI PROM via JTAG through the > FPGA (Indirect SPI programming) but I can't find anything on how to get > Impact to do this. > > Does anyone know how this is done please? > > TIA. > > Rog. Hi, Please read App not xapp974.pdf on xilins website. You should get the idea. Rajkumar...Article: 135816
On Oct 16, 5:12=A0pm, Nathan Bialke <nathan.bia...@gmail.com> wrote: > You probably don't want what you are describing, so please explain why > you need that particular construct. Further, what you are describing > cannot be constructed from logic components, so please explain how you > expect that to be implemented in your FPGA. > > - Nathan > > On Oct 16, 7:03=A0am, aleksa <aleks...@gmail.com> wrote: > > > > > if falling_edge(clock2) then > > =A0 =A0 =A0 =A0 out2 <=3D data2; > > end if; > > > if clock2=3D'0' then out1 <=3D 'Z'; > > elsif falling_edge(clock1) then out1 <=3D data1; > > end if; > > > (This is just a sample VHDL) > > > Clock2 is used both as a GCK and as a signal. > > > ISE (10.1) complains on Spartan 2. > > > I've tried replacing clock2 with clock2a: > > =A0 =A0 =A0 =A0 signal clock2a : STD_LOGIC; > > > =A0 =A0 =A0 =A0 component ibufg port ( > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 O : out STD_LOGIC; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I : in =A0STD_LOGIC); > > =A0 =A0 =A0 =A0 end component; > > > =A0 =A0 =A0 =A0 attribute box_type : string; > > =A0 =A0 =A0 =A0 attribute box_type of ibufg : component is "black_box"; > > > =A0 =A0 =A0 =A0 temporary : ibufg port map (I =3D> clock2, O =3D> clock= 2a); > > > From the manual: "The IBUFG can be routed to your choice of logic > > to allow the use of the dedicated clock pins for general logic." > > Am I using it the correct way? > > > I've also tried variations of buffer_type, no luck either. > > =A0 =A0 =A0 =A0 attribute buffer_type: string; > > =A0 =A0 =A0 =A0 attribute buffer_type of clock2: signal is "bufgp"; > > > Even if I get it to work on this small example, ISE always > > complains on the complete project. > > > Currently, I connect clock two 2 pins, GCK and a IOB, but this > > can probably be avoided. How?- Hide quoted text - > > - Show quoted text - This is more closer to what I am actually doing/trying: Here, WR is used as GCK and also as signal: -- main CPU writes a command to slave CPU, via FPGA if rising_edge(WR) and <other coditions, like address..> then COMMAND <=3D DBUS; -- register command end if; -- slave CPU ready flag if WR=3D'0' and <same other coditions..> then READY <=3D '0'; -- write detected, signal slave CPU is busy elsif rising_edge(SLAVE_CPU_ACK) then READY <=3D '1'; end if; (I need this READY signal to be edge sensitive, not level, since slave CPU is really slow.) Another example is a bi-dir data bus (RD is also used as GCK, elsewhere): DBUS <=3D DATAOUT when RD=3D'0' else "ZZZZZZZZ"; ISE gives warning (again, it works on Spartan 3): MapLib:95 - IBUF symbol "RD_IBUF" (output signal=3DRD_IBUF1) is promoted to indicate the use of GCLKIOB site.Article: 135817
Rajkumar, Thanks very much. Don't know how I'd missed this. Shame it wasn't referenced in the Impact Help on this subject. Roger. "Rajkumar" <shubamshreyas@gmail.com> wrote in message news:a8cbd288-869b-42c2-9fec-915f2b34036c@s20g2000prd.googlegroups.com... > On Oct 16, 8:24 pm, "Roger" <rogerwil...@hotmail.com> wrote: >> I've read that it's possible to program an SPI PROM via JTAG through the >> FPGA (Indirect SPI programming) but I can't find anything on how to get >> Impact to do this. >> >> Does anyone know how this is done please? >> >> TIA. >> >> Rog. > > Hi, > Please read App not xapp974.pdf on xilins website. You should get the > idea. > > Rajkumar...Article: 135818
On Oct 15, 1:47=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > (comp.dcom.lans.ethernet added) > > Fred wrote: > > I have the IEEE standard 802.3 documents but find they're not the most > > readable in the world. =A0I find they confuse issues by having many > > standards in one document. > > Is there a more readable document around which is specifically related > > to 100Base-TX? > > Does any one know of example waveforms I could include in a test > > bench, so I can check the scrambling and descrambling of data? =A0I am > > aware of a very good site for 10Base-T not for for fast ethernet. > > comp.dcom.lans.ethernet is probably the place to ask. > > Otherwise, I recommend Rich Seifert's book: > > http://search.barnesandnoble.com/Gigabit-Ethernet/Rich-Seifert/e/9780... > > Yes, despite the name he discusses previous ethernet standards. > > -- glen Hi Glen, Very much appreciate your response - will try in the alternative news group. Generally if it's been done in an FPGA it would have been done by someone here and would have sourced some literature, other than the IEEE documents. I've ordered the book, it was quite cheap second hand from Amazon. Many thanks again. FredArticle: 135819
On 16 Oct, 16:04, Benjamin Couillard <benjamin.couill...@gmail.com> wrote: > On 16 oct, 06:40, Leon <leon...@btinternet.com> wrote: > > > > > On 15 Oct, 20:28, Anton Erasmus <nob...@spam.prevent.net> wrote: > > > > On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter > > > > <p...@pcserviceselectronics.co.uk> wrote: > > > >In article > > > > =A0<3d4b6f41-b742-405d-87bd-47e2fb75a...@8g2000hse.googlegroups.com= >, > > > >leon...@btinternet.com says... > > > >> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote: > > > >> > Bob wrote about XMOS: > > > > >> > > They seem far too fixated on doing everything in software, thi= ngs like > > > >> > > ethernet where there is no point shoveling bytes in software i= f > > > >> > > hardware can take care of it. > > > >> > Leon wrote: > > > >> > > They are supplying free libraries for all the usual peripheral > > > >> > > functions. Doing stuff like that in software is much cheaper t= han > > > >> > > using hardware, and easier in many ways. > > > > >> > Been there, done that, and it's not cheaper or easier when you > > > >> > consider the overall system cost impact, not just the "benefit" = of > > > >> > leaving out the hardware block. =A0That was the path Scenix/Ubic= om went > > > >> > down, calling it "virtual peripherals", and it was not very > > > >> > successful. =A0Ubicom has since added hardware for Ethernet, USB= , > > > >> > etc. to their most recent parts. =A0The reality is that a hardwa= re > > > >> > Ethernet MAC costs less than the total system cost impact of the > > > >> > software alternative. > > > > >> > Eric > > > > >> Not if you have four 400 MIPS cores on the chip, each with 64 bits= of > > > >> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32 > > > >> threads per core, with switching between threads in one clock. If = the > > > >> software is free, it is a very cost-effective solution, especially= as > > > >> the chips will be very cheap. > > > > >The PC market solution to determinisity - > > > > > =A0 =A0"If in doubt put bigger processor(s) and > > > > =A0 =A0 lots more memory to solve the 'problem'" > > > > >Having seen how easily screwed even software UARTs can get, and > > > >when something goes wrong all other activity is screwed. > > > > >The PC example is dodgy CD inserted, nothing else can work until > > > >the upto 30 seconds of lockout. Lots of other examples exist. > > > > >This sort of software emulation of hardware ONLY is useful for > > > >cheap and nasty commodity products that assume that unusability > > > >is always solved by a reset (for some products that means host PC > > > >AS WELL!). > > > > >This means for the VAST majority of *my* applications it is useless. > > > > I fully agree with this. Software is flexible and easier to correct > > > than hardware. Unfortunantely this has lead to the current thinking > > > that we can ship the product with known issues, since "We can always > > > fix it later". In most cases these fixes never happen. I would prefer > > > more peripherals in hardware, not less. TCP/IP stack in hardware, USB > > > stack in hardware etc. Something like IEEE-1394 is much more reliable > > > than USB, since all the enumeration etc is handled by the hardware. > > > With the right hardware support, which can be a few gates, software > > > can often be made much simpler, more robust and faster. A simple thin= g > > > like an atomic increment or decrement can be quite complex to > > > implement in software. In hardware it is trivial. In my experience > > > from porting code written for old hardware, to new hardware. > > > Calculation tasks are much faster on modern hardware. Moving data > > > around between buffers, and peripherals is only a little bit faster i= f > > > at all. Simple things like hardware that provides the amount of space > > > available in a FIFO in a register in stead of just a FIFO has space > > > flag, can easily make the moving of data easily 5x faster. > > > > Regards > > > =A0 Anton Erasmus- Hide quoted text - > > > > - Show quoted text - > > > However, XMOS will be supplying fully tested and characterised "plug- > > in" software modules, which will get round the problems you mention. > > The XC language makes this very straightforward. > > > Leon > > Seriously, how much are they paying you? Nothing! I just like the devices. > > To be fair, the XMOS seems like a promising device, I might consider > using it someday, but it still hasn't been widely tested in real > designs. > > How many MACs can it perform? Do you have benchmarks for FFTs, IIR > filtering, FIR Filtering? What if you want to interface it to a DDR-II > SDRAM module? I'm still at the flashing LED stage. I'll ask those questions at the seminar next week. It can do a MAC in one cycle and it has all the usual DSP stuff in the instruction set but I'm not sure how they are accessed via the compilers. I'll be adding a header to my board tomorrow, so that I can interface my own hardware to it easily. LeonArticle: 135820
Andreas Ehliar wrote: > On 2008-10-16, Jim Granville <no.spam@designtools.maps.co.nz> wrote: > >>No mention of leading zero suppression ? > > > I haven't really thought about it, but that would make a nice addition :) > > >>>What kind of display would you use here? (7 segment LEDs? LCD?, etc?) >> >>MUX'd or Non MUX'd ? >>LCDs need a XOR backplane, and they also have MUX choices too. > > > I didn't use a mux'd solution, but as you point out further down I'm > cheating somewhat with my choice of LED drivers. MUX'd would probably > be better if using traditional driver circuits like the ULN2003. You can direct drive LEDs from CPLDs, and I'd tend to pull the LED block into its own PLD, so students can partition the tasks more easily. It could manage a 5 wire nibble Mux bus for example: rising edge Digit, falling edge Data and give you the choice of MUX or De-Nux-Static or even LCD Display Blocks. With a little care, this could even be two-way, and read-back buttons/IDs from the display block in a couple of 16 address slots .. or a TV block ? a while ago I recall working a 7 segment TV display into a CPLD - it's really just a time-gymnastic special case of a normal MUX (but with fewer output pins ;) . > >>50Hz, 60Hz and 32.768KHz are the common ones.... > > > 50 Hz and 60 Hz are quite hard if you want to do some kind of resource sharing. > If you use 32768 Hz it is much easier to move things around to only one > arithmetic block. a good system should be able to use any of these clock sources... :) > >>You could get them to code direct 7 segment counters, for a non-mux >>display. Nice to show there are non Bin/bcd counters possible too... > > > I haven't thought about that at all, that is a very interesting counter idea. > It is probably not going to be useful in many cases but you never know when > something similar will save your day :) We did an ATF22V10 direct 7 seg counter, and managed Up/Dn/RippleBlank and Async RST. These mounted one behind each largish LED digit, and IIRC did 8-9 digits for a Quadrature display readout. > >>>Personally, I have a relatively small solution to this, but there are still >>>a few tricks I haven't used. In my solution I'm using a 7 segment LED driver >>>circuit with built in NBCD decoder (the 9368), so if you want to compare >>>your solution to mine you might want to output NBCD coded numbers out of your >>>CPLD. >> >>Surely the 9368 should be part of the CPLD ? > > > Yes. But I had to use some sort of LED driving circuit, and we had lots of 9368 > in the lab :) Perhaps I'll try to update my solution to use a more traditional > LED driver instead. Unfortunately that is probably going to mean that I have to > use a larger CPLD as the current version is filled to the limit. On the other > hand, that would also allow me to fit a clock prescaler into the CPLD to avoid > the very non-standard frequency the current solution needs :) See above, I would move the 'display-block' into a separate CPLD and split the task for students. Gets them used to interfacing with someone else's design block. -jgArticle: 135821
On Oct 16, 10:08=A0am, aleksa <aleks...@gmail.com> wrote: > On Oct 16, 5:12=A0pm, Nathan Bialke <nathan.bia...@gmail.com> wrote: > Here, WR is used as GCK and also as signal: I would suggest not doing that. > > -- main CPU writes a command to slave CPU, via FPGA > > =A0 =A0 =A0 =A0 if rising_edge(WR) and <other coditions, like address..> = then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 COMMAND <=3D DBUS; =A0 -- register comman= d > =A0 =A0 =A0 =A0 end if; > > -- slave CPU ready flag > > =A0 =A0 =A0 =A0 if WR=3D'0' and <same other coditions..> then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '0'; =A0 -- write detected, si= gnal slave CPU is busy > > =A0 =A0 =A0 =A0 elsif rising_edge(SLAVE_CPU_ACK) then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '1'; > =A0 =A0 =A0 =A0 end if; > > (I need this READY signal to be edge sensitive, > not level, since slave CPU is really slow.) I would suggest that you don't want to do your bus interface this way. The way you are following is fraught with danger. There are also much easier ways to do what I think you want to do. Specifically, if the slave CPU is really slow, make a synchronous interface yourself by synchronizing the CPU signals into the FPGA timing domain. > Another example is a bi-dir data bus (RD is also used as GCK, > elsewhere): > > =A0 =A0 =A0 =A0 DBUS <=3D DATAOUT when RD=3D'0' else "ZZZZZZZZ"; > > ISE gives warning (again, it works on Spartan 3): > > MapLib:95 - IBUF symbol "RD_IBUF" (output signal=3DRD_IBUF1) > is promoted to indicate the use of GCLKIOB site. I would suggest that your design probably isn't working in a Spartan-3 as well as you think. Using asynchronous control signals as clocks is not going to work particularly well in any FPGA.Article: 135822
Hi I have implemented a very simple 5-stage pipeline processor that offers instructions similar to the MIPS processor. Now I have made some changes to the microarchitecture of the processor in order that it processes some specific workloads in less time. Obvioulsy, this approach requires in turn more area. Now I would be interested to compare these two different design choices in terms of power consumption while executing a specific algorithm. Is there a special tool out there that I could use for this purpose? In addition, would it be possible to make power estimations for an ASIC implementation of these two approaches (might be different to an FPGA implementation)? Thanks for any feedback, PhilippArticle: 135823
Andreas Ehliar wrote:
> The purpose of this post is to try to get a discussion going
> on various design tricks for severely limited devices like CPLDs.
> On that note I'll pose the following challenges to the group:
> Challenge 2 - A digital watch with as few CPLDs as possible
> -----------------------------------------------------------
>
> This is an easier problem which should require fewer or smaller CPLDs
> than the previous challenge.
>
> As a baseline, the students I have supervised who do this kind of project
> end up with about 3 or 4 CPLDs. (Either XC9572 or XC95108.) They usually
> don't bother with any kind of resource sharing though...
I've dug into the corners of the harddrive :)... and found a CarClock
PLD - this is slightly simpler, using HH:MM and uses FastMin and FastHrs
set buttons. (no alarm., no stop watch)
It has non-mux 7 seg LED drive, and accepts 50Hz/60Hz/4Hz (32.768+HC4060)
Fits into the smallest CPLD (32 macrocell) ATF1502ASL (or ATF1502BE) as
LED or bumps into ATF1504ASL with LCD display option.
Resource map is below
-jg
Atmel ATF1502 Fitter Version 1919 ,running Fri Oct 17 09:35:32 2008
MCell Pin# Oe PinDrive DCERP FBDrive DCERP Foldback
CascadeOut TotPT SO
MC1 4 on HourL0 C---- Div0 Dg--- -- --
3 f-
MC2 5 on HourL1 C---- nFastHour L---- -- --
3 f-
MC3 6 on HourL2 C---- nFastMin L---- ClkEHUnits --
3 f-
MC4 7 on HourL4 C---- MUnits2 Dgeg- NA --
5 f-
MC5 8 on HourL3 C---- Div2 Dge-- NA --
5 f-
MC6 9 on HourL5 C---- MUnits1 Dgeg- NA --
5 f-
MC7 11 on HourL6 C---- Div1 Dge-- nClkEHUnits --
5 f-
MC8 12 on MinL0 C---- MTens1 Dgeg- nNettTC --
5 f-
MC9 13 on MinL1 C---- MTens0 Dgeg- TC_TenMin --
5 f-
MC10 14 on MinL2 C---- MTens2 Dgeg- nTC_ThreeHr --
4 f-
MC11 16 on MinL3 C---- HUnits0 Dgeg- NA --
5 f-
MC12 17 -- HUnits3.CE C---- TC_TenHr --
3 f-
MC13 18 on MinL5 C---- HUnits1 Dgeg- NA --
5 f-
MC14 19 on MinL4 C---- HUnits2 Dgeg- NA --
5 f-
MC15 20 on MinL6 C---- HTens0 Dgeg- nTC_HalfSec --
5 f-
MC16 21 on HourU6 Dge-p -- nTC_TenMin --
4 f-
MC17 41 -- -- -- --
0 f-
MC18 40 on HourU5 C---- -- -- --
2 f-
MC19 39 on MinU0 C---- ClkEMins L---- -- --
3 f-
MC20 38 on MinU1 C---- nClkEMins L---- -- --
2 f-
MC21 37 on MinU2 C---- MUnits0 Dgeg- -- --
3 f-
MC22 36 on MinU3 C---- HUnits3 Dgeg- -- --
4 f-
MC23 34 on MinU5 C---- MUnits3 Dgeg- -- --
4 f-
MC24 33 on MinU4 C---- Div3 Dge-- NA --
5 f-
MC25 32 on Colon C---- Div4 Dge-- -- --
3 f-
MC26 31 on MinU6 C---- Div5 Dge-- -- --
3 f-
MC27 29 on HourU1 C---- Secs0 Dgeg- -- --
3 f-
MC28 28 on HourU0 C---- Secs3 Dgeg- -- --
3 f-
MC29 27 on HourU2 C---- Secs1 Dgeg- -- --
3 f-
MC30 26 on HourU4 C---- Secs4 Dgeg- -- --
3 f-
MC31 25 on HourU3 C---- Secs5 Dgeg- TC_OneMin --
4 f-
MC32 24 -- Secs2 Dgeg- nTC_OneMin --
3 f-
MC0 2 FastHourB INPUT -- -- --
0 f-
MC0 1 ClrAll INPUT -- -- --
0 f-
MC0 44 FastMinB INPUT -- -- --
0 f-
MC0 43 CLK INPUT -- -- --
0 f-
Logic Array Block Macro Cells I/O Pins Foldbacks TotalPT FanIN Cascades
A: MC1 - MC16 30/16(187%) 15/16(93%) 8/16(50%) 70/80(87%) 23/40(57%) 0
B: MC17 - MC32 28/16(175%) 14/16(87%) 2/16(12%) 48/80(60%) 26/40(65%) 0
Total dedicated input used: 4/4 (100%)
Total I/O pins used 29/32 (90%)
Total Macro cells used 58/32 (181%)
Total Flip-Flop used 29/32 (90%)
Total Foldback logic used 10/32 (31%)
Total Nodes+FB/MCells 68/32 (212%)
Total cascade used 0
Total input pins 4
Total output pins 29
Total Pts 118
---------------- End fitter, Design FITS
$Device PLCC44 fits; JTAG OFF; Secure OFF
Article: 135824On 16 Oct, 21:43, Philipp Falke <P.Fa...@hotmail.com> wrote: > Hi > > I have implemented a very simple 5-stage pipeline processor that offers > instructions similar to the MIPS processor. Now I have made some changes > to the microarchitecture of the processor in order that it processes > some specific workloads in less time. Obvioulsy, this approach requires > in turn more area. Now I would be interested to compare these two > different design choices in terms of power consumption while executing a > specific algorithm. Is there a special tool out there that I could use > for this purpose? In addition, would it be possible to make power > estimations for an ASIC implementation of these two approaches Sure. Either Synopsys' or Cadence's synthesis tools will give you a power estimate if you feed in toggle data from either an RTL or gate- level simulation (the latter being more accurate). Jon
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