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 Oct 13, 12:10 am, Brian Drummond <brian_drummond wrote: > discovered a j in your pension fund? The j is orthogonal to my problems; it's the j^2 that worries me :-) -- Jonathan BromleyArticle: 135701
MMJ wrote: >>Why does this need to be on the FPGA ? >>SoftCPUs still need external memory, so are a 2-3 chip solution. > > > Correct, but the FPGA is a "must have" in this project, so an embedded > softcore will give us allot of advantages: > > *No extra BOM cost for MCU and needed extra components. Here you need care: Your SoftCPU needs external Code memory, so that adds to the BOM (unless you just happen to be using large external memory anyway, with unused space, that can fit the CODE, and also happen to have spare bus cycles to access it. It also might need a larger Config memory, another BOM adder, and you might also need a larger FPGA. You also have higher EMC issues, and could even need more PCB layers.... If that external memory is ONLY for code, that is a LOT of pins you have added to the design.... > *No additional use of "real estate" for the MCU subsystem. Single chip MCUs are quite small, and the flash is all done. Generally, if you can fit your code into a merchant uC, it makes more sense to use one, along side your (now smaller?) FPGA > *High data bandwidt between our custom hardware and CPU. How high do you need ? > *"Weird" hardware configurations are supported (e.g. we need 4+ i2c busses). Nothing stops you adding 4 i2c in the FPGA > > These pros has made us going for the softcore soloution. -jgArticle: 135702
>> That's the way I've been describing bus tri-states since I started >> FPGA design 15 odd years ago. As far as I know it's a 'standard' >> so the tools should be able to deal with it. > So have I but I've sometimes seen it not to work > Nicolas Which doesn't fill me full of confidence in the Actel tools. I tend to design at a very (too) low level and have been using 80MHz as a 'standard' clock speed for about the last 10 years. My designs tend to easily build & work with a simple clock constraint and IO constraints. This has been the case with multiple designs in Altera and Xilinx devices. The design that ran at 66MHz in the Cyclone I (not a II) is struggling to meet that in the Actel device, this is after removing some registers to ease up the critical path. I'm starting to look at Lattice devices, the first pass run in an XP2 ran at 95MHz. This is without pin constraints, so it will be slower then that but it looks much more like the performance I'm used to. NialArticle: 135703
On Oct 10, 2:01 pm, Leon <leon...@btinternet.com> wrote: > I've just ordered my 1600 MIPS XMOS XC-1 design kit. > > The XMOS chips will replace DSPs and FPGAs in a lot of applications. > > I haven't been so excited about a new chip since the transputer came > out. David May designed them both, of course. > > Leon > leon...@btinternet.com I briefly saw XMOS at a trade show in London. 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. The quarter VGA touchscreen on the dev kit has novelty value. I'm not sure the performance justifies the effort of using somthing so unusual in most cases. I'd want to make a single lifetime buy of processors if I used these in a product. Far too likely to dissapear without trace. BobArticle: 135704
On 13 Oct, 11:14, Bob <b...@mailinator.com> wrote: > On Oct 10, 2:01 pm, Leon <leon...@btinternet.com> wrote: > > > I've just ordered my 1600 MIPS XMOS XC-1 design kit. > > > The XMOS chips will replace DSPs and FPGAs in a lot of applications. > > > I haven't been so excited about a new chip since the transputer came > > out. David May designed them both, of course. > > > Leon > > leon...@btinternet.com > > I briefly saw XMOS at a trade show in London. > 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. > > The quarter VGA touchscreen on the dev kit has novelty value. > > I'm not sure the performance justifies the effort of using somthing > so unusual in most cases. > > I'd want to make a single lifetime buy of processors if I used > these in a product. Far too likely to dissapear without trace. > > Bob 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. LeonArticle: 135705
On Oct 12, 8:04=A0am, FP <FPGA.unkn...@gmail.com> wrote: > On Oct 12, 8:02=A0am, FP <FPGA.unkn...@gmail.com> wrote: > > > Hello, > > > I am a newbie and I would like your help. What is a DDR Flop? I found > > IFDDR and OFDDR primitives from Xilinx. However, I cannot find more > > information on this topic. > > > Your comments are appreciated. > > I would like to use this to genrate a 200MHz clock from a 100 MHz > source. The point of DDR is that you can get 200 megabits per second out a single I/O clocked at 100 MHz. That doesn't mean that you have 200 MHz anywhere in the system. In fact the highest frequency you deal with is 100 MHz. The OFDDR has two D inputs, one sampled on the rising clock edge (usually) and the other on the falling clock edge (again usually). In the Xilinx DDR flops you don't have to use both edges of a single clock for this as the OFDDR also has two independent clock inputs, but normally the two clocks would either be an inversion or 50% of period delay of eachother. I think there are some older Xilinx appnotes with reference designs for DDR memory control that can illustrate how these DDR flip-flops are used. Regards, GaborArticle: 135706
> If you say what the specific bugs are, maybe I can offer some help or > advice. One of the main problems are the poor performance of the debug interface in the Mico32. A download speed of 20-30 kbit/sec is just to slow when developing large applications. Is there any way to speed up this interface? > MicroBlaze and NIOS II have been around for longer and no doubt have a > larger user base, but they are not without their own problems. Don't > forget that much of the toolchain is pretty much the same s/w. Offcourse! But you mention a big reasson to try out Altera....the large user base. Lattice have < 100 topics in their forum compared to >8k in Alteras. The large user may help you to find/fight some of the problems. Regards -- MMJArticle: 135707
MMJ wrote: > Offcourse! But you mention a big reasson to try out Altera....the large user > base. Lattice have < 100 topics in their forum compared to >8k in Alteras. > The large user may help you to find/fight some of the problems. Maybe there are less topics because there are less problems :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 135708
On Oct 13, 5:39=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > >> That's the way I've been describing bus tri-states since I started > >> FPGA design 15 odd years ago. As far as I know it's a 'standard' > >> so the tools should be able to deal with it. > > So have I but I've sometimes seen it not to work > > Nicolas > > Which doesn't fill me full of confidence in the Actel tools. > > I tend to design at a very (too) low level and have been using 80MHz as > a 'standard' clock speed for about the last 10 years. My designs > tend to easily build & work with a simple clock constraint and > IO constraints. This has been the case with multiple designs in > Altera and Xilinx devices. > > The design that ran at 66MHz in the Cyclone I (not a II) is struggling > to meet that in the Actel device, this is after removing some registers > to ease up the critical path. > > I'm starting to look at Lattice devices, the first pass run in an > XP2 ran at 95MHz. This is without pin constraints, so it will be > slower then that but it looks much more like the performance I'm used to. > > Nial I have run into problems with IOB placement especially in older versions of XST. The newer versions seem to cope with more issues, but often I still need to coerce them a bit. Some points that confused various versions of XST synthesis: 1) Describing registers in a different level of hierarchy than the pin. Usually this was register in a lower level and pin at the top. 2) Defining active high enable for tristate control. Newer versions invert the function to the D flop but older ones could not place register into IOB because of the inverter after the flop. 3) Not explicitly replicating the tristate function. Newer versions would do this automatically, but I had to turn off "equivalent register removal" as well as turn on "register duplication" to make it work. There may be similar knobs on the Actel synthesis tools. Regards, GaborArticle: 135709
On Oct 13, 8:19=A0am, Gabor <ga...@alacron.com> wrote: > On Oct 12, 8:04=A0am, FP <FPGA.unkn...@gmail.com> wrote: > > > On Oct 12, 8:02=A0am, FP <FPGA.unkn...@gmail.com> wrote: > > > > Hello, > > > > I am a newbie and I would like your help. What is a DDR Flop? I found > > > IFDDR and OFDDR primitives from Xilinx. However, I cannot find more > > > information on this topic. > > > > Your comments are appreciated. > > > I would like to use this to genrate a 200MHz clock from a 100 MHz > > source. > > The point of DDR is that you can get 200 megabits per second out a > single I/O clocked at 100 MHz. =A0That doesn't mean that you have 200 > MHz anywhere in the system. =A0In fact the highest frequency you deal > with is 100 MHz. =A0The OFDDR has two D inputs, one sampled on > the rising clock edge (usually) and the other on the falling clock > edge (again usually). =A0In the Xilinx DDR flops you don't have to use > both edges of a single clock for this as the OFDDR also has two > independent clock inputs, but normally the two clocks would either > be an inversion or 50% of period delay of eachother. > > I think there are some older Xilinx appnotes with reference designs > for DDR memory control that can illustrate how these DDR > flip-flops are used. > > Regards, > Gabor Thank you all for your valuable comments. I appreciate it.Article: 135710
> Here you need care: > Your SoftCPU needs external Code memory, so that adds to the BOM > (unless you just happen to be using large external memory anyway, with > unused space, that can fit the CODE, and also happen to have spare bus > cycles to access it. > It also might need a larger Config memory, another BOM adder, and > you might also need a larger FPGA. > You also have higher EMC issues, and could even need more PCB layers.... > If that external memory is ONLY for code, that is a LOT of pins > you have added to the design.... External flash for code is needed yes - but is also used on most silicon MCU/MPUs. Config memeory for the FPGA will be selected to support a fully configured FPGA. Regarding EMC and PCB we acutally keep allot of signals within the FPGA by embedding the CPU, which eases routing and maybe decreasses layers. > Single chip MCUs are quite small, and the flash is all done. Correct....if the job can be done at the right price by an internal flash MCU. > Generally, if you can fit your code into a merchant uC, it > makes more sense to use one, along side your (now smaller?) FPGA No the size of the CPU in the FPGA is very few percent relative to the custom hardware that needs to be implemented. > How high do you need ? Above 10Mbit on a buffered DMA interface. Internally in the FPGA I guess this can be done by DMA from FPGA RAM to DDR ram of the CPU. Complette control of interrupt loading etc. -- MMJArticle: 135711
MMJ pisze: >> Here you need care: >> Your SoftCPU needs external Code memory, so that adds to the BOM >> (unless you just happen to be using large external memory anyway, with >> unused space, that can fit the CODE, and also happen to have spare bus >> cycles to access it. >> It also might need a larger Config memory, another BOM adder, and >> you might also need a larger FPGA. >> You also have higher EMC issues, and could even need more PCB layers.... >> If that external memory is ONLY for code, that is a LOT of pins >> you have added to the design.... > > External flash for code is needed yes - but is also used on most silicon > MCU/MPUs. Config memeory for the FPGA will be selected to support a fully > configured FPGA. Regarding EMC and PCB we acutally keep allot of signals > within the FPGA by embedding the CPU, which eases routing and maybe > decreasses layers. > If you have enough space inside configuration flash you can use it for both - for FPGA image and for softprocessor code. I'm doing this way. AdamArticle: 135712
On 9 Okt., 01:01, Selensky <selen...@gmail.com> wrote: > Hi Peter, > You said that Virtex-4 IDELAY element is stable over temperature, > voltage and processing. Is it stable over continuous years of > operation too? While the IDELAY element itself is stable, IO routing inside the FPGA is not. Have a look at the tables at the end of XAPP856. They show that the clock vs. data routing show a relative drift of 1 delay tap with temperature and 6 delay taps with supply voltage. The data is for Virtex-5. Kolja SulimmaArticle: 135713
On Wed, 08 Oct 2008 07:35:44 -0700, Pratap wrote: > Hi, > I want to synthesize a delay of around 10 ns in Xilinx Virtex2 Pro. So I > put around 200 inverters in series and get the desired delay. So I did > port map the BASIC cell "INV" according to the XST settings. But when i > place and route I guess the optimizer removes all the intermediate > buffers and I get very less delay when I do a post route simulation. > How can I get rid of this problem? > Thanks in advance. > -Pratap Do you need a delay or can you accomplish your task with a phase shifted clock? If you can use a phase shifted clock from the DCM that's a much better way of doing it because it's stable over temperature and process and because it won't change when the tools change. If you must build a delay line from buffers you will have to directly place them because the routing delays are much more important then the LUT delays. Also you should use an XOR instead of an inverter. Tie one side of the XOR to a flop which presets to 1 on reset and then clocks a zero into the data input. This will be enough to fool XST and PAR into leaving the components alone.Article: 135714
> There may be similar knobs on the Actel synthesis tools. Perhaps, but the guy who's been looking at this doesn't know what they are. Nial.Article: 135715
Adam Górski pisze: > MMJ pisze: >>> Here you need care: >>> Your SoftCPU needs external Code memory, so that adds to the BOM >>> (unless you just happen to be using large external memory anyway, with >>> unused space, that can fit the CODE, and also happen to have spare >>> bus cycles to access it. >>> It also might need a larger Config memory, another BOM adder, and >>> you might also need a larger FPGA. >>> You also have higher EMC issues, and could even need more PCB layers.... >>> If that external memory is ONLY for code, that is a LOT of pins >>> you have added to the design.... >> >> External flash for code is needed yes - but is also used on most >> silicon MCU/MPUs. Config memeory for the FPGA will be selected to >> support a fully configured FPGA. Regarding EMC and PCB we acutally >> keep allot of signals within the FPGA by embedding the CPU, which >> eases routing and maybe decreasses layers. >> > > If you have enough space inside configuration flash you can use it for > both - for FPGA image and for softprocessor code. > > I'm doing this way. > > Adam If you have external SDR SDRAM or DDR SDRAM of course or big enough internal ram AdamArticle: 135716
Nial Stewart a écrit : > > Which doesn't fill me full of confidence in the Actel tools. As I said in my first post on this topic, I have no experience with Actel. NicolasArticle: 135717
Hello! I would like to write image files (*.bmp, ...) to micro-SD card. I am using Spartan 3e starter kit with microblaze soft processor and a micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/ Pmod-B.html). The general idea is to write files in FAT16 file system to micro-SD card and then later transfer them to PC. Does anybody have an idea (or reference design) how to do this? Is it possible to use DOSFS? Thanks!Article: 135718
On 11 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7=A8, 12:00, "HT-Lab" <han...@h= t-lab.com> wrote: > "bzigon" <bob.zi...@gmail.com> wrote in message > > news:62c7a069-d995-415b-a77e-4e0c87cb7e2f@x41g2000hsb.googlegroups.com... > > > Gang > > > I'm looking for a simple 32bit softcore processor in VHDL. I dont need > > a cache or > > and MMU. I do need interrupts. I also need software tools for the > > processors. > > I am happy to program in assembler, a C compiler is a bonus. > > > Any ideas? > > > Bob > > Google? > Why 32bits? > Opencoreshttp://www.opencores.org/browse.cgi/filter/category_microprocess= or > > Hanswww.ht-lab.com I recommend too to use leon. I used it for an I2C example (http://bknpk.no-ip.biz)Article: 135719
On Oct 13, 10:06=A0am, pfri...@yahoo.co.uk wrote: > Hello! > > I would like to write image files (*.bmp, ...) to micro-SD card. > I am using Spartan 3e starter kit with microblaze soft processor and a > micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/ > Pmod-B.html). > The general idea is to write files in FAT16 file system to micro-SD > card and then later transfer them to PC. > Does anybody have an idea (or reference design) how to do this? Is it > possible to use DOSFS? > > Thanks! We use a PicoBlaze in a Spartan 3e to read a bit file from a mini-SD card and program it into a Virtex-4FX, so a MicroBlaze should not have any problems with being able to write to a microSD card. Being able to fit reading from a FAT16 file system was a tight fit for the PicoBlaze. Once the PicoBlaze configures the Virtex on our card, it turns ownership of the miniSD card over to the Virtex. The V4 then has a simple boot loader that loads Linux from the miniSD card. Linux has full read write access to the miniSD card. We have the card formatted as FAT16. The PicoBlaze accesses the card in four bit mode, and has DMA assist so that it can program the V4 fast enough for it to be configured in time to respond to a PCI bus probe. The V4 just uses the miniSD in SPI mode. For SPI mode, we use the SPI core that comes with EDK. Linux has a FAT16 file system driver, so that is one good place to start looking. EDK also comes with a FAT16 file system in the xilfatfs library. Xilfatfs requires the system ace controller, but you have the source code to the library so you could modify it to use microSD if you wish. Regards, John McCaskill www.FasterTechnology.comArticle: 135720
Hi: I need to test some VHDL codes, which are commanding the LTC1407-A Analog-to-Digital converter of the Spartan-3A, to take a sample on its voltage input pin. The results of the conversion will be displayed on the LCD. The problem is that my background is not in electrical engineering and I would like to know of a way (online tutorial, etc) to test these codes, by sending the voltage output of the digital-to-analog- converter (LTC2624 model) to the input pin of the analog-to-digital converter. I already confirmed, through an oscilloscope, that the DAC is sending the voltage as I need it. Basically the FPGA application sends a voltage and immediately after that, commands the analog-to-digital converter to take a sample. I have a cable, which bought in the Digilent Web site for the pins of both terminals. A "6 Pin MTE Cable" found at : http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable .. however I received the advise that I need to make by myself a circuit to join the ground pin with another pin... and that for these steps I need to work with a resistor... etc... [ honestly I didn't understand much ] Is there a simpler way to successfully send the voltage output of the Digital-to-Analog converter to the voltage input of the Analog-to- Digital converter? Thank you, m __ m __________________________ LTC1407-A : http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1155,C1001,C1150,P2485 LTC2624 (DAC) : http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1155,C1005,C1156,P2048Article: 135721
steveu@coppice.org wrote: > On Oct 11, 1:43 am, Leon <leon...@btinternet.com> wrote: >> On 10 Oct, 17:42, ste...@coppice.org wrote: >> >> >> >>> On Oct 10, 9:01 pm, Leon <leon...@btinternet.com> wrote: >>>> I've just ordered my 1600 MIPS XMOS XC-1 design kit. >>>> The XMOS chips will replace DSPs and FPGAs in a lot of applications. >>>> I haven't been so excited about a new chip since the transputer came >>>> out. David May designed them both, of course. >>>> Leon >>>> leon...@btinternet.com >>> Is the comparison with the Transputer supposed to imply this is a half >>> thought out design with brain dead execution? :-\ >>> Steve >> The transputer was ahead of its time, and really pushed the technology >> that was available. I sold a lot of systems using it, mostly to >> universities and research establishments, because there was nothing >> else around with that sort of performance then. Inmos even had their >> own fab! >> >> Leon > > The Transputer wasn't ahead of its time. It was brain dead. A chip > only effective in substantial arrays selling for hundreds of pounds > per device was a dead duck from the start. The only people who could > seriously look at it for substantial arrays were military > applications. However, when approached about military parts Transputer > gave evasive answers. > > There was nothing innovative about the design of the Transputer. The > device as it was supposed to be (i.e. separate comms and execution > planes), rather than the crippled one they shipped, was similar to > designs several people in the UK (and presumably elsewhere) were > toying with at that time. The others did not proceed because the > economics looked so wrong. Toying means nothing in our industry, it's all about rolling out actual product. That is what Inmos did. But: The economics didn't have to look wrong. They were wrong because IMHO a cardinal mistake had been made: Entering the market with very high price tags. That was bound to fail and cause me to turn away. Same thing happened with S/C filter chips. Next, they should have lined up an early licensing deal with a major semiconductor manufacturer, one that engineers trust. This is extremely important. Nobody in their right mind would design in a single-source part from a tiny manufacturer without a serious business track record. My guess is that a few more business-thinkers could have potentially saved the bacon at Inmos. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 135722
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. That was the path Scenix/Ubicom went down, calling it "virtual peripherals", and it was not very successful. Ubicom has since added hardware for Ethernet, USB, etc. to their most recent parts. The reality is that a hardware Ethernet MAC costs less than the total system cost impact of the software alternative. EricArticle: 135723
pfrinec@yahoo.co.uk writes: > I am using Spartan 3e starter kit with microblaze soft processor and a > micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/ > Pmod-B.html). You mean there's actually a way to purchase those? > Is it possible to use DOSFS? I don't see why not. I've used DOSFS to access flash cards on other platforms.Article: 135724
On Oct 13, 10:47=A0pm, Eric Smith <e...@brouhaha.com> wrote: > pfri...@yahoo.co.uk writes: > > I am using Spartan 3e starter kit with microblaze soft processor and a > > micro-SD adapter for PMOD extension slot (http://www.microdream-1.com/ > > Pmod-B.html). > > You mean there's actually a way to purchase those? > http://www.trenz-electronic.de/ Trenz electronic has them in stock and several Xilinx kits are shipping with them as bundled package from Trenz webshop > > Is it possible to use DOSFS? > > I don't see why not. =A0I've used DOSFS to access flash cards on other > platforms. I have ported and packaged DOSFS as EDK software library and it is very easy to use the low level driver required may use different type of peripherals 1) SPI core 2) software SPI over GPIO 3) SD 1-bit mode over GPIO 4) SD 1-bit mode over custom IP http://code.google.com/p/dev-kit/downloads/list is the EDK packaged DOSFS library for the low level drivers i need to cleanup and upload them what will happen shortly now Antti
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