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 Mar 12, 2:24=A0am, Jacko <jackokr...@gmail.com> wrote: > Hi > > > so how much stack you get into the maxII- 570? > > None. indirect memory access is used. > > Cheers jacko Dear Creative technologist Simon jackson, BEng. if nibz can not work from inside MAXII-570 (without external memory) then it is absolutly no need to mention MAXII at all. If nibz needs external ram, then it is is 200% sure nobody will ever use it in MAXII 570 hence the logic utilization comparison to MAXII-570 LE's is absolutly meaningless and confusing... MAXII is a bad FPGA, as Altera made design mistakes (no distributed ram!) so it is also bad idea to use reference to it for marketing. unless... unless your processor could work with MAXII and not external components!! I do have a MAXII optimized processor design that fits <240 MAXII LE's and is useable, but it was real hard design and compromise to get it useable at all. Very small soft-cores are possible and useable as example Actel CoreABC can be optimized by GUI settingsto very very low logic utilization. Using CoreABC to perform SD card init SD/SDHC for SD mode (not SPI) yields to Actel utilization of about 640 Verstaliles. Versatiles are 3 input logic, and much smaller than MAXII LE as they can not use FF in same LE where logic is utilized. this CoreABC config implements the ROM in logic made out of 3 input LE's, and the example utilization is smaller than 570 if compared to MAXII LE's. And the example is verified in real FPGA with real SD card. your SD card boot mentioned, have you ever tried it on real FPGA? the CoreABC SD card init worked the VERY first time tested on real FPGA with real SD. And it was programmed in assembler. in Assembler for a architecture previously unknown to me. you claim your forth to be somewhat portable, so one should think it would be simple to get programs working right? so why havent you to verified the SD card boot? back to nibz-MAXII, if you talk about 1000's of cores to be used then well they must run from internal block rams, and MAXII doesnt have them, those you should provide some design for other architectures, and examples how the nibz arrays work about your licensing, sorry to be joy-killer but: your total earnings from the paypal donation that you advertize on your site will be about 42$ for the all product lifetime. belive me, this number is highly accurate. your "logo" request: no large scale company will ever consider adding the current bad quality bitmap image of he Kring logo to any ASIC or product PCB. Should it happen I will go buy a hat just to be able to eat it. jacko - I am not the bad guy, any feedback is good feedback, really! Most people just dont care. I am still looking for a good small soft-core, and well it seem not to exist... it not nibz for sure. Even if the nibz arch it super the doc and related tools are missing or cryptic, so nobody would ever take the effort to really evaluate and understand what you have done, it too much time needed. AnttiArticle: 138826
On Mar 12, 2:39=A0am, "Symon" <symon_bre...@hotmail.com> wrote: > "doug" <x...@xx.com> wrote in message > > news:uL2dnXB7JbmqoiXUnZ2dnUVZ_qjinZ2d@posted.docknet... > > > > > > > Antti wrote: > > >> if i think of it, it should be doable? > > >> but i do not recall any projects that would use such transmit method > > >> normal FPGA LVDS are fast enough that it would be possible just > >> capacitive decoupling > >> sure some encoding should be applied but that shouldnt also be a > >> problem > > >> Antti > > > Yes it is possible, no, it is not a good idea. Running cables > > through the world always get you transients. It is much better > > to put a hardened lvds driver onto external cables since they > > are easier to replace than fpgas. We have done this both > > ways. > > Doug, > I strongly disagree. A few reversed biased PIN diodes, some TVS diodes, a= nd > judicious routing beats 'hardened lvds drivers' every time. On cost, > reliability, performance, manufacturability and board space. > I would like to take this opportunity revise my original post, and recomm= end > 8B10B coding to get rid of DC bias problem. 8B10B is out of patent now... > HTH., Syms. Hi thanks for all the answers, i also think it should be doable without external drivers Xilinx MGTs are qualified for PCIe and SATA, so I assume they might be used for PCIe over cable and eSATA, and in such cases there would be same situation as using ac decoupled CAT5 with LVDS I/Os, transient protection is of course good thing for any external cabling! AnttiArticle: 138827
On 12 Mrz., 05:05, Digi Suji <digis...@gmail.com> wrote: > Hi, > > I am trying to read a byte from a particular address in I2C EEPROM. > But the data I get is from a different location. For example, if try > to read data from "x05" location, the byte from "x0B" location is > read. If try to read data from "x06" location, data from "x0D" is > read. If I try to read data from "x07", data from "x0F" is read. If > you notice above situation, a fixed pattern is followed. > > I am using a I2C Master Core controller to read data from I2C EEPROM. > Xilinx Post route simulation works fine but when I try to configure > the Spartan 3E FPGA, I get the above described results. I2C EEPROM is > external to the FPGA and I2C controller goes in to the FPGA. > > I am confused as to why is this happening. Can any one please help. > > Thanks. Hi Digi, look at the bits: wanted result 0101 1011 0110 1101 0111 1111 so your adress bits are shifted one to the left and the last bit is filled up with a '1'. Probably your clocking scheme on the i2c Interface is wrong somehow. Check it! If the fpga internal stuff is reliable, then you have to look at the board. Is there noise? Too much capacitive load? Routing delays? Have a nice synthesis EilertArticle: 138828
On Mar 12, 1:34=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > > MAXII is a bad FPGA, as Altera made design mistakes (no distributed > ram!) > so it is also bad idea to use reference to it for marketing. unless... Does Altera have *any* FPGAs with distributed ram? I thought that distributed ram (using the LUT ram as real ram) was patented by Xilinx although Lattice has a license to use it (they got it when they bought the Lucent ORCA line which Lucent licensed from Xilinx). I think this patent is still in force although it is likely reaching its end of life in a very few years. I think distributed ram is much less important now although I will say it can come in handy. I am looking at using it in a possible design, not in place of the block ram, but because I don't have enough block ram! I need a sizable delay line and I need another 208 bytes of delay. So I'll use 104 LUTs in a serial chain along with two blocks of ram. That will leave 4 blocks for the on chip CPU. > unless your processor could work with MAXII and not external > components!! > > I do have a MAXII optimized processor design that fits <240 MAXII LE's > and is useable, but it was real hard design and compromise to get > it useable at all. Very small soft-cores are possible and useable as > example Actel CoreABC can be optimized by GUI settingsto very > very low logic utilization. Is your CPU available to view? I am always interested in a decent CPU design for FPGAs. > your SD card boot mentioned, have you ever tried it on real FPGA? > the CoreABC SD card init worked the VERY first time tested on > real FPGA with real SD. And it was programmed in assembler. > in Assembler for a architecture previously unknown to me. I am very interested in any code to access SD cards. One idea I would like to put into place is to put a CPU in my test fixture FPGA which would read a bit stream from the SD card and program the FPGA on the target board/UUT. Then it would read a second file which contains the test procedure and conduct the test of the UUT. I'm not certain that I can do this because I am sharing I/ O lines between the SD card and some RS-422 chips used to test the UUT. So the SD card would have to be removed and then plugged back in for every card. Still, I would be interested in your code, or even just the info you used to understand how to read it. I assume you are using a file system and not just treating the SD as a flash memory. > I am still looking for a good small soft-core, and well it seem > not to exist... I seem to recall that you were trying to find a bit serial CPU that would be the smallest possible in an FPGA. Did you ever find one you liked? Personally, I think that is a goal with a very low target application size. But certainly there are some apps where this could be useful. My potential app might will work with such a processor. It will be receiving 16 bit data at a 1 kHz rate which it will decode into a 200 bps bit stream with 2 bits per symbol at 100 Hz symbol rate (and/or the other direction). That is pretty low bandwidth. A potential future app would be the same algorithm at 10x the data rates. My existing processor design was using around 600 LUTs in an Altera ACEX 1K part. I have not yet ported it to my new target, a Lattice XP device (block ram, but no multipliers). If I take out some of the stuff intended for debugging, it might be as small as 400 LUTs, but I can't be sure just yet. RickArticle: 138829
On Mar 11, 3:34=A0pm, VAX9...@gmail.com wrote: > On Mar 11, 3:00=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: > > > On Wed, 11 Mar 2009 11:49:03 -0700 (PDT), VAX9...@gmail.com wrote: > > >Hi, > > > =A0I am inexperienced in CPLD design. I am using a slow CPU (PC ISA > > >port) and LUT based CPLD (Altera MAX II) in my design. I implemented > > >many control registers (implemented with D FF) in the CPLD that the > > >CPU will write from time to time. The ISA bus is slow, with a write > > >cycle of several hundred ns. The CPLD is running on 50ns primary > > >clock. > > > >I am facing two choices of implementing the register writing signals. > > > You can't be VERY inexperienced - you are asking the right > > question :-) > > Thank you for your answer. I am an experienced TTL amateur designer, > but CPLD or FPGA is different, especially when I could not watch the > resulted routing because I am using the free web- software. It is like > working in the darkness with a pair of sunglasses. > > > The ISA bus is so dog-slow that it is almost certainly > > easiest to oversample the write strobe and use that to > > establish a write-enable, synchronous to the internal 20MHz > > clock, occurring at a time when you know that the write > > address and data are stable. > > > If the write strobe is shorter than 3 internal clock cycles, > > it's not safe to do oversampling and instead you need to > > implement a handshake across the clock domains. =A0This is > > sure to be more troublesome, although it's not too hard. > > I think you suggested the single clock domain solution. I will give it > a try. Thank you! I agree. A single clock domain solves so many problems, or more accurately, focuses all of the problems into one, well defined area, the sampling of the incoming signals. 50 ns is fast enough that you can sample with two FFs on opposite edges of the 50 ns clock and get excellent metastability rejection. I did a similar design once and did just that. I don't remember my clock rate, but it actually varied between a fast clock and a slow rate of around 2 MHz. This allowed the power consumption of the circuit to be greatly reduced. I used a very tricky design to make it work while the clock ranged between slower and faster than the bus rate. I don't recall the details (it was some 8 years ago), but if you need it, I could dig it up. If you want to do this yourself for fun, then go for it! BTW, when I couldn't remember how I solved that problem, it cost me a job offer. I spoke with the head of a small/mid sized company and he asked me to describe a tough design problem I had solved and to describe my thought process. I immediately thought of this one, since it took me two days to figure out how to do it, but couldn't remember how I solved it!!! Needless to say he was not impressed. He wouldn't let me switch to another one either. I had to stand in front of the chalk board and look stupid for some 10 minutes while I failed to have any idea of how I made that work. And I'm not very used to feeling stupid when it doesn't involve the other gender ;^) Needless to say, I didn't get an offer from these guys. That never used to happen to me either. Maybe it was age discrimination... yeah, that's the ticket! RickArticle: 138830
On Mar 12, 8:57=A0pm, rickman <gnu...@gmail.com> wrote: > I seem to recall that you were trying to find a bit serial CPU that > would be the smallest possible in an FPGA. =A0Did you ever find one you > liked? =A0Personally, I think that is a goal with a very low target > application size. =A0But certainly there are some apps where this could > be useful. Bit-serial (like Cop8) only makes size-sense to simplify bus routing. - but that's almost free in a FPGA, so other needs better drive Bit- Serial. Bit-serial Multiply/divide can save resource, but that's less a core than an algortihm trade-off, and Mul/Div are rare in the smallest cores anyway. One plus that appeals to me, is Execute from Serial FLASH, (and now Serial RAM) [does a nibble fetch from 4 bit SPI still count as Bit-serial ? ] as resource space. Saves MANY pins, and PCB space, but I'm not sure the core will be _smaller_ as a result - more likely slightly larger ? -jgArticle: 138831
Hello! My team is doing real time machine vision project in Spartan3a dsp 1800 board. We took greyscale data from c3038 camera module and succesfully performed sobel edge detection in hardware. Now we are detecting lines form the binary image fed to microblaze processor We have to perform iterations to determine the value of r from the following equation r = x*cos(t) + y*sin(t) for each (x,y) from t= -90 degree to 90 degree We have thought some solutions:- I) USING FLOATING POINT UNIT OF MICROBLAZE 7 AND PERFORMING THE CALCULATION WITH SINE /COSINE LOOKUP TABLE KEPT IN MEMORY II) USING CORDIC/ SINECOSINE LUT CORE CONECTED TO MICROBLAZE THROUGH FSL LINK CAN ANY BODY SUGGESTS ME ANY OTHER SOLUTION FOR MY PROBLEM THANK YOUArticle: 138832
On Mar 12, 2:46=A0am, goo...@twinmail.de wrote: > On 12 Mrz., 05:05, Digi Suji <digis...@gmail.com> wrote: > > > > > Hi, > > > I am trying to read a byte from a particular address in I2C EEPROM. > > But the data I get is from a different location. For example, if try > > to read data from "x05" location, the byte from "x0B" location is > > read. If try to read data from "x06" location, data from "x0D" is > > read. If I try to read data from "x07", data from "x0F" is read. If > > you notice above situation, a fixed pattern is followed. > > > I am using a I2C Master Core controller to read data from I2C EEPROM. > > Xilinx Post route simulation works fine but when I try to configure > > the Spartan 3E FPGA, I get the above described results. I2C EEPROM is > > external to the FPGA and I2C controller goes in to the FPGA. > > > I am confused as to why is this happening. Can any one please help. > > > Thanks. > > Hi Digi, > look at the bits: > > wanted =A0 =A0result > 0101 =A0 =A0 =A01011 > 0110 =A0 =A0 =A01101 > 0111 =A0 =A0 =A01111 > > so your adress bits are shifted one to the left and the last bit is > filled up with a '1'. > Probably your clocking scheme on the i2c Interface is wrong somehow. > Check it! > > If the fpga internal stuff is reliable, then you have to look at the > board. Is there noise? > Too much capacitive load? Routing delays? > > Have a nice synthesis > =A0 Eilert Since you didn't design the I2C core yourself, the likelihood is that the core works correctly with some kind of slave attached. Perhaps your EEPROM is doing clock-stretching and this is not handled in the core? If that is the case, you may be able to work around it by reducing the SCL frequency until the EEPROM doesn't need to stretch the clock. Regards, GaborArticle: 138833
I WANT TO IMAGE DATA SEND FROM EDGE DETECTION MODULE IN DDR2 RAM OF SPARTAN 3A DSP 1800 BOARD AND LATER ACCES IT THROUGH MICROBLAZE. I can't find appropiate tutorils for this type of problem. Does any body has solution / refernces for such problem?????????? thank youArticle: 138834
On Mar 12, 2:41=A0pm, SUMAN <suman...@gmail.com> wrote: > I WANT TO IMAGE DATA SEND FROM EDGE DETECTION MODULE IN DDR2 RAM OF > SPARTAN 3A DSP 1800 BOARD AND LATER ACCES IT THROUGH MICROBLAZE. > > I can't find appropiate tutorils for this type of problem. > > Does any body has solution / refernces for such problem?????????? > > thank you just connect your data source to MPMC NPI port AnttiArticle: 138835
SUMAN wrote: > Hello! > > My team is doing real time machine vision project in Spartan3a dsp > 1800 board. We took greyscale data from c3038 camera module and > succesfully performed sobel edge detection in hardware. Now we are > detecting lines form the binary image fed to microblaze processor > We have to perform iterations to determine the value of r from the > following equation > r = x*cos(t) + y*sin(t) for each (x,y) from t= -90 degree to 90 > degree > > We have thought some solutions:- > > I) USING FLOATING POINT UNIT OF MICROBLAZE 7 AND PERFORMING THE > CALCULATION WITH SINE /COSINE LOOKUP TABLE KEPT IN MEMORY > > II) USING CORDIC/ SINECOSINE LUT CORE CONECTED TO MICROBLAZE THROUGH > FSL LINK > > CAN ANY BODY SUGGESTS ME ANY OTHER SOLUTION FOR MY PROBLEM > > THANK YOU Once you've fixed your caps lock key, I'd go for a lookup table. You could easily have a static table for your sin() and cos() - you are not going to need many steps for t. If you decide to calculate it at startup using a soft processor, there is no need to use a floating point unit - software floating point (or fixed point algorithms, such as cordic) will be fine unless you need great speed and accuracy while calculating the table.Article: 138836
On 12 Mar, 05:34, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 12, 2:24 am, Jacko <jackokr...@gmail.com> wrote: > > > Hi > > > > so how much stack you get into the maxII- 570? > > > None. indirect memory access is used. > > > Cheers jacko > > Dear Creative technologist Simon jackson, BEng. > > if nibz can not work from inside MAXII-570 (without external memory) > then it is absolutly no need to mention MAXII at all. If nibz needs > external ram, then it is is 200% sure nobody will ever use it in MAXII > 570 If you remove the ports (40 programmable IO pins) the design will shrink, and free some space for a very small RAM area. > hence the logic utilization comparison to MAXII-570 LE's is absolutly > meaningless and confusing... > > MAXII is a bad FPGA, as Altera made design mistakes (no distributed > ram!) > so it is also bad idea to use reference to it for marketing. unless... Marketting ? > unless your processor could work with MAXII and not external > components!! > > I do have a MAXII optimized processor design that fits <240 MAXII LE's > and is useable, but it was real hard design and compromise to get > it useable at all. Very small soft-cores are possible and useable as > example Actel CoreABC can be optimized by GUI settingsto very > very low logic utilization. > > Using CoreABC to perform SD card init SD/SDHC for SD mode (not SPI) > yields to Actel utilization of about 640 Verstaliles. Versatiles are 3 > input > logic, and much smaller than MAXII LE as they can not use FF in same > LE where logic is utilized. > > this CoreABC config implements the ROM in logic made out of 3 input > LE's, and the example utilization is smaller than 570 if compared to > MAXII LE's. And the example is verified in real FPGA with real SD > card. > > your SD card boot mentioned, have you ever tried it on real FPGA? > the CoreABC SD card init worked the VERY first time tested on > real FPGA with real SD. And it was programmed in assembler. > in Assembler for a architecture previously unknown to me. Sounds good. > you claim your forth to be somewhat portable, so one should > think it would be simple to get programs working right? I do no t claim any thing of MY forth, it is a non complete gforth EC port. > so why havent you to verified the SD card boot? For the same rason. > back to nibz-MAXII, if you talk about 1000's of cores to be used > then well they must run from internal block rams, and MAXII > doesnt have them, those you should provide some design > for other architectures, and examples how the nibz arrays work Quarus II allows migration to Hard Copy II with 10 minuites. > about your licensing, sorry to be joy-killer but: > your total earnings from the paypal donation that you advertize on > your site will be about 42$ for the all product lifetime. > belive me, this number is highly accurate. Probbably. > your "logo" request: no large scale company will ever consider > adding the current bad quality bitmap image of he Kring logo > to any ASIC or product PCB. Should it happen I will go buy a > hat just to be able to eat it. A hat with an ARM logo perhaps ;-) > jacko - I am not the bad guy, any feedback is good feedback, > really! Most people just dont care. ok. > I am still looking for a good small soft-core, and well it seem > not to exist... it not nibz for sure. Even if the nibz arch it super > the doc and related tools are missing or cryptic, so nobody > would ever take the effort to really evaluate and understand > what you have done, it too much time needed. Probably.Article: 138837
On 12 Mar, 07:57, rickman <gnu...@gmail.com> wrote: > On Mar 12, 1:34 am, "Antti.Luk...@googlemail.com" > > <Antti.Luk...@googlemail.com> wrote: > > > MAXII is a bad FPGA, as Altera made design mistakes (no distributed > > ram!) > > so it is also bad idea to use reference to it for marketing. unless... > > Does Altera have *any* FPGAs with distributed ram? I thought that > distributed ram (using the LUT ram as real ram) was patented by Xilinx > although Lattice has a license to use it (they got it when they bought > the Lucent ORCA line which Lucent licensed from Xilinx). I think this > patent is still in force although it is likely reaching its end of > life in a very few years. Cyclone -> Statix -> HardCopy. M4K blocks other. > I think distributed ram is much less important now although I will say > it can come in handy. I am looking at using it in a possible design, > not in place of the block ram, but because I don't have enough block > ram! I need a sizable delay line and I need another 208 bytes of > delay. So I'll use 104 LUTs in a serial chain along with two blocks > of ram. That will leave 4 blocks for the on chip CPU. ok. > > unless your processor could work with MAXII and not external > > components!! > > > I do have a MAXII optimized processor design that fits <240 MAXII LE's > > and is useable, but it was real hard design and compromise to get > > it useable at all. Very small soft-cores are possible and useable as > > example Actel CoreABC can be optimized by GUI settingsto very > > very low logic utilization. > > Is your CPU available to view? I am always interested in a decent CPU > design for FPGAs. > > > your SD card boot mentioned, have you ever tried it on real FPGA? > > the CoreABC SD card init worked the VERY first time tested on > > real FPGA with real SD. And it was programmed in assembler. > > in Assembler for a architecture previously unknown to me. > > I am very interested in any code to access SD cards. One idea I would > like to put into place is to put a > CPU in my test fixture FPGA which would read a bit stream from the SD > card and program the FPGA on the target board/UUT. Then it would read > a second file which contains the test procedure and conduct the test > of the UUT. I'm not certain that I can do this because I am sharing I/ > O lines between the SD card and some RS-422 chips used to test the > UUT. So the SD card would have to be removed and then plugged back in > for every card. Still, I would be interested in your code, or even > just the info you used to understand how to read it. I assume you are > using a file system and not just treating the SD as a flash memory. > > > I am still looking for a good small soft-core, and well it seem > > not to exist... > > I seem to recall that you were trying to find a bit serial CPU that > would be the smallest possible in an FPGA. Did you ever find one you > liked? Personally, I think that is a goal with a very low target > application size. But certainly there are some apps where this could > be useful. > > My potential app might will work with such a processor. It will be > receiving 16 bit data at a 1 kHz rate which it will decode into a 200 > bps bit stream with 2 bits per symbol at 100 Hz symbol rate (and/or > the other direction). That is pretty low bandwidth. A potential > future app would be the same algorithm at 10x the data rates. > > My existing processor design was using around 600 LUTs in an Altera > ACEX 1K part. I have not yet ported it to my new target, a Lattice XP > device (block ram, but no multipliers). If I take out some of the > stuff intended for debugging, it might be as small as 400 LUTs, but I > can't be sure just yet. > > Rick cheers jackoArticle: 138838
I have a 32 deep 5 bits wide Xilinx FIFO and would like to have it initialized with known value for all 32 entries. I can have this done in logic - right after reset. But is there a way to preinitiailze the FIFO without adding extra logic? I am looking for power on reset value that I can program for all 32 entries. Thanks.Article: 138839
On Mar 12, 9:57=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 12, 1:34=A0am, "Antti.Luk...@googlemail.com" > > <Antti.Luk...@googlemail.com> wrote: > > > MAXII is a bad FPGA, as Altera made design mistakes (no distributed > > ram!) > > so it is also bad idea to use reference to it for marketing. unless... > > Does Altera have *any* FPGAs with distributed ram? =A0I thought that > distributed ram (using the LUT ram as real ram) was patented by Xilinx > although Lattice has a license to use it (they got it when they bought > the Lucent ORCA line which Lucent licensed from Xilinx). =A0I think this > patent is still in force although it is likely reaching its end of > life in a very few years. > > I think distributed ram is much less important now although I will say > it can come in handy. =A0I am looking at using it in a possible design, > not in place of the block ram, but because I don't have enough block > ram! =A0I need a sizable delay line and I need another 208 bytes of > delay. =A0So I'll use 104 LUTs in a serial chain along with two blocks > of ram. =A0That will leave 4 blocks for the on chip CPU. > > > unless your processor could work with MAXII and not external > > components!! > > > I do have a MAXII optimized processor design that fits <240 MAXII LE's > > and is useable, but it was real hard design and compromise to get > > it useable at all. Very small soft-cores are possible and useable as > > example Actel CoreABC can be optimized by GUI settingsto very > > very low logic utilization. > > Is your CPU available to view? =A0I am always interested in a decent CPU > design for FPGAs. > > > your SD card boot mentioned, have you ever tried it on real FPGA? > > the CoreABC SD card init worked the VERY first time tested on > > real FPGA with real SD. And it was programmed in assembler. > > in Assembler for a architecture previously unknown to me. > > I am very interested in any code to access SD cards. =A0One idea I would > like to put into place is to put a > CPU in my test fixture FPGA which would read a bit stream from the SD > card and program the FPGA on the target board/UUT. =A0Then it would read > a second file which contains the test procedure and conduct the test > of the UUT. =A0I'm not certain that I can do this because I am sharing I/ > O lines between the SD card and some RS-422 chips used to test the > UUT. =A0So the SD card would have to be removed and then plugged back in > for every card. =A0Still, I would be interested in your code, or even > just the info you used to understand how to read it. =A0I assume you are > using a file system and not just treating the SD as a flash memory. > > > I am still looking for a good small soft-core, and well it seem > > not to exist... > > I seem to recall that you were trying to find a bit serial CPU that > would be the smallest possible in an FPGA. =A0Did you ever find one you > liked? =A0Personally, I think that is a goal with a very low target > application size. =A0But certainly there are some apps where this could > be useful. > > My potential app might will work with such a processor. =A0It will be > receiving 16 bit data at a 1 kHz rate which it will decode into a 200 > bps bit stream with 2 bits per symbol at 100 Hz symbol rate (and/or > the other direction). =A0That is pretty low bandwidth. =A0A potential > future app would be the same algorithm at 10x the data rates. > > My existing processor design was using around 600 LUTs in an Altera > ACEX 1K part. =A0I have not yet ported it to my new target, a Lattice XP > device (block ram, but no multipliers). =A0If I take out some of the > stuff intended for debugging, it might be as small as 400 LUTs, but I > can't be sure just yet. > > Rick Hi Rick, my CPU is available for view, if i find it again.. its on the search path over 6 external HDD's as of distributed RAM it looks the patent is hold by: Altera Corporation, not Xilinx http://www.freepatentsonline.com/5352940.html but maybe i need sunglasses and no, i havent found the dream CPU yet ;) as always need todo it itself i guess AnttiArticle: 138840
On Thu, 12 Mar 2009 00:39:32 -0000, "Symon" <symon_brewer@hotmail.com> wrote: > >"doug" <xx@xx.com> wrote in message >news:uL2dnXB7JbmqoiXUnZ2dnUVZ_qjinZ2d@posted.docknet... >> >> >> Antti wrote: >> >>> if i think of it, it should be doable? >>> >>> but i do not recall any projects that would use such transmit method >>> >>> normal FPGA LVDS are fast enough that it would be possible just >>> capacitive decoupling >>> sure some encoding should be applied but that shouldnt also be a >>> problem >>> >>> Antti >> >> Yes it is possible, no, it is not a good idea. Running cables >> through the world always get you transients. It is much better >> to put a hardened lvds driver onto external cables since they >> are easier to replace than fpgas. We have done this both >> ways. > >Doug, >I strongly disagree. A few reversed biased PIN diodes, some TVS diodes, and >judicious routing beats 'hardened lvds drivers' every time. On cost, >reliability, performance, manufacturability and board space. >I would like to take this opportunity revise my original post, and recommend >8B10B coding to get rid of DC bias problem. 8B10B is out of patent now... >HTH., Syms. If the patent was ever valid. The BBC were using a form of 8B10B coding (not,AFAIK, the exact same form as was patented but one with a delightfully simple implementation) for digital video transmission in early 1982; somewhat ahead of the priority date on the most-often quoted patent (though there may be other patents) - BrianArticle: 138841
If we use VHDL integer arithmetic as a model, all operations are promoted to 32 bit signed (i.e. the largest size available), regardless of the subranges or signedness of the operands. Then the results are automatically truncated upon assignment to a subranged (and either natural or integer) object. Synthesis will prune intermediate results based on the final truncation. One VHDL arithmetic type not mentioned in the paper is the new ieee fixed point types (ufixed & sfixed), which also work well for integers with a zero rightmost index (i.e. zero digits to the right of the binary point). What is different between fixed point (ufixed & sfixed) and numeric_std (signed & unsigned) arithmetic, is that addition/ subtraction is always promoted by one bit to handle potential overflow, which effectively duplicates the promotion part of the behavior of integer arithmetic. Unfortunately, what is not included is the promotion of ufixed operands to an sfixed result for subtraction. This is really interesting since subtraction of two ufixed operands still increases the bit size by one, but still does not make it signed. There is also no definition of any operators for mixed ufixed/ sfixed operands. I think "fixing" the automatic truncation of vectors on assignment is probably on the "too hard" list without changing a lot of existing behavior in the VHDL language, unless overloading the assignment operator was allowed. Promotion of all results to sfixed (save perhaps addition of two ufixed operands) is not too hard, and should be considered, especially since a truncation function is almost always needed anyway, and could be combined with a sfixed/ufixed conversion. With these additions/changes, the fixed point type model could go a long ways toward providing integer-like arithmetic with arbitrary width data. AndyArticle: 138842
On 12 Mar, 15:09, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 12, 9:57=A0am, rickman <gnu...@gmail.com> wrote: > > > > > > > On Mar 12, 1:34=A0am, "Antti.Luk...@googlemail.com" > > > <Antti.Luk...@googlemail.com> wrote: > > > > MAXII is a bad FPGA, as Altera made design mistakes (no distributed > > > ram!) > > > so it is also bad idea to use reference to it for marketing. unless..= . > > > Does Altera have *any* FPGAs with distributed ram? =A0I thought that > > distributed ram (using the LUT ram as real ram) was patented by Xilinx > > although Lattice has a license to use it (they got it when they bought > > the Lucent ORCA line which Lucent licensed from Xilinx). =A0I think thi= s > > patent is still in force although it is likely reaching its end of > > life in a very few years. > > > I think distributed ram is much less important now although I will say > > it can come in handy. =A0I am looking at using it in a possible design, > > not in place of the block ram, but because I don't have enough block > > ram! =A0I need a sizable delay line and I need another 208 bytes of > > delay. =A0So I'll use 104 LUTs in a serial chain along with two blocks > > of ram. =A0That will leave 4 blocks for the on chip CPU. > > > > unless your processor could work with MAXII and not external > > > components!! > > > > I do have a MAXII optimized processor design that fits <240 MAXII LE'= s > > > and is useable, but it was real hard design and compromise to get > > > it useable at all. Very small soft-cores are possible and useable as > > > example Actel CoreABC can be optimized by GUI settingsto very > > > very low logic utilization. > > > Is your CPU available to view? =A0I am always interested in a decent CP= U > > design for FPGAs. > > > > your SD card boot mentioned, have you ever tried it on real FPGA? > > > the CoreABC SD card init worked the VERY first time tested on > > > real FPGA with real SD. And it was programmed in assembler. > > > in Assembler for a architecture previously unknown to me. > > > I am very interested in any code to access SD cards. =A0One idea I woul= d > > like to put into place is to put a > > CPU in my test fixture FPGA which would read a bit stream from the SD > > card and program the FPGA on the target board/UUT. =A0Then it would rea= d > > a second file which contains the test procedure and conduct the test > > of the UUT. =A0I'm not certain that I can do this because I am sharing = I/ > > O lines between the SD card and some RS-422 chips used to test the > > UUT. =A0So the SD card would have to be removed and then plugged back i= n > > for every card. =A0Still, I would be interested in your code, or even > > just the info you used to understand how to read it. =A0I assume you ar= e > > using a file system and not just treating the SD as a flash memory. > > > > I am still looking for a good small soft-core, and well it seem > > > not to exist... > > > I seem to recall that you were trying to find a bit serial CPU that > > would be the smallest possible in an FPGA. =A0Did you ever find one you > > liked? =A0Personally, I think that is a goal with a very low target > > application size. =A0But certainly there are some apps where this could > > be useful. > > > My potential app might will work with such a processor. =A0It will be > > receiving 16 bit data at a 1 kHz rate which it will decode into a 200 > > bps bit stream with 2 bits per symbol at 100 Hz symbol rate (and/or > > the other direction). =A0That is pretty low bandwidth. =A0A potential > > future app would be the same algorithm at 10x the data rates. > > > My existing processor design was using around 600 LUTs in an Altera > > ACEX 1K part. =A0I have not yet ported it to my new target, a Lattice X= P > > device (block ram, but no multipliers). =A0If I take out some of the > > stuff intended for debugging, it might be as small as 400 LUTs, but I > > can't be sure just yet. > > > Rick > > Hi Rick, > > my CPU is available for view, if i find it again.. its on the search > path over 6 external HDD's > > as of distributed RAM it looks the patent is hold by: > > Altera Corporation, not Xilinx > > http://www.freepatentsonline.com/5352940.html > > but maybe i need sunglasses Look into FLEX8000 etc architecture. The reason for MAXII design is I have a MAXII 1270 Devkit (PCI/USB one). Then the 570 IIZ chips came out and I wondered if I could make something that small, I can say the extra restriction of the 570 helped in reducung logic count, even though I'll use 1270 for any possible product. It is possible to remove the IO programmable, and the instruction counter to lower logic count. Also removing the UFM_parallel mega block would cause a significant logic reduction. So if you arrange your own IO forrget the ufm 512 flash (ROM), the bidirectionality of the IO and don't need clock counting, then there would be space for some RAM. The patent quoted relates to using RAM as PLA or RAM. cheers jackoArticle: 138843
rickman wrote: > On Mar 5, 2:42 pm, justforpret...@gmail.com wrote: >> I hope this isn't terribly inappropriate to post here. I want to buy >> three FPGA-related T-shirts. I know that Altera and Xilinx have in >> the past given out freebie shirts, and I'm trying to track some down >> as gifts for my roommates, who work with FPGAs. I will pay good money >> for them!! >> >> Let me know if you have something lying around that you don't mind >> parting with. They primarily use Altera, so that's preferable. > > > This will be a good test to see if the vendors still monitor this > group. I can't imagine that a vendor would not want to reward such > loyal customers. > > I hope that's not laying it on too thick... ;^) > > Rick I at least still monitor the group, but we really haven't done much in the way of t-shirts give aways in the last few years that I'm aware of. Ed McGettigan -- Xilinx Inc.Article: 138844
On Mar 11, 3:35=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > if i think of it, it should be doable? > > but i do not recall any projects that would use such transmit method > > normal FPGA LVDS are fast enough that it would be possible just > capacitive decoupling > sure some encoding should be applied but that shouldnt also be a > problem > > Antti I'm curious why you're interested in capacitive coupling. And - if you're looking at distant devices with grounds that can be a few volts off from each other - what data rates are you targeting? I'm thinking it might be reasonable to use ethernet magnetics to get rid of the bias problem yet still keep your data rates reasonable. The Cat5 system I did in a Spartan3e was fed (eventually) by the same power supply so isolation wasn't an issue for me. I designed for 600 Mb/s per channel but scaled back to about 400 Mb/s in the final design. - John_HArticle: 138845
On Mar 12, 7:53=A0am, cpan...@yahoo.com wrote: > I have a 32 deep 5 bits wide Xilinx FIFO and would like to have it > initialized with known value for all 32 entries. =A0I can have this done > in logic - right after reset. =A0But is there a way to preinitiailze the > FIFO without adding extra logic? =A0I am looking for power on reset > value that I can program for all 32 entries. > > Thanks. You can initialize individual SRL elements but there are two difficulties here: 1) the values are for 16 bits of depth, 1 wide, making the translation of values a bit of a labor, and 2) the HDL inference of your 32-deep, 5 wide structure tends not to have names you can count on. As synthesizers evolve, you may have luck specifying initial values. I know Synplify wasn't supporting this capability in the years it was a Synplicity product and my long-ago attempt to initialize a single bit width FIFO in XST produced some odd (though accurate) results with the initial values. The Verilog language allows specifying initial values but there isn't much support for power-up reset initialization of these values. - John_HArticle: 138846
On Mar 12, 7:09=A0pm, newsgr...@johnhandwork.com wrote: > On Mar 11, 3:35=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > > > if i think of it, it should be doable? > > > but i do not recall any projects that would use such transmit method > > > normal FPGA LVDS are fast enough that it would be possible just > > capacitive decoupling > > sure some encoding should be applied but that shouldnt also be a > > problem > > > Antti > > I'm curious why you're interested in capacitive coupling. =A0And - if > you're looking at distant devices with grounds that can be a few volts > off from each other - what data rates are you targeting? =A0I'm thinking > it might be reasonable to use ethernet magnetics to get rid of the > bias problem yet still keep your data rates reasonable. =A0The Cat5 > system I did in a Spartan3e was fed (eventually) by the same power > supply so isolation wasn't an issue for me. =A0I designed for 600 Mb/s > per channel but scaled back to about 400 Mb/s in the final design. > > - John_H curiuos? was just thinking of extending SPI like comms using cheapest and ready made cabling so one pair in each direction only. was hoping to get 50mbit/s? eSata uses capacitive decoupling, so i do not see big issues for cap decoupled LVDS, but yes special IC maybe more robust. and.. i do not like any wires direct to FPGA or MCU either (going off board/cable), have seen a Atmel to bulk erase itself because the reset line was in 2 meter long cable parallel to wire carrying 12V (reed relay switched) (well Atmel claimed such bulk erase is impossible... but it happened twice and second time i had another guy to witness it, so i wasnt seeing ghosts) so i would normally design some buffer or at least current limiting resistor for any wires going off board AnttiArticle: 138847
hi 292 LEs fully stripped, no ROM, no RAM no IO pins, 16 bit address, 16 bit data Bus. Expected 20-30MHz, (36 pins plus power), About 10 MIPS at 20MHz. cheers jackoArticle: 138848
Symon wrote: > "doug" <xx@xx.com> wrote in message > news:uL2dnXB7JbmqoiXUnZ2dnUVZ_qjinZ2d@posted.docknet... > >> >>Antti wrote: >> >> >>>if i think of it, it should be doable? >>> >>>but i do not recall any projects that would use such transmit method >>> >>>normal FPGA LVDS are fast enough that it would be possible just >>>capacitive decoupling >>>sure some encoding should be applied but that shouldnt also be a >>>problem >>> >>>Antti >> >>Yes it is possible, no, it is not a good idea. Running cables >>through the world always get you transients. It is much better >>to put a hardened lvds driver onto external cables since they >>are easier to replace than fpgas. We have done this both >>ways. > > > Doug, > I strongly disagree. A few reversed biased PIN diodes, some TVS diodes, and > judicious routing beats 'hardened lvds drivers' every time. On cost, > reliability, performance, manufacturability and board space. > I would like to take this opportunity revise my original post, and recommend > 8B10B coding to get rid of DC bias problem. 8B10B is out of patent now... > HTH., Syms. It kind of depends on how long you want them to work. One good chip giving several reliable lines takes no more spaces than your set of protectors. It also depends on how hard it is to get to the circuit to fix it. If it is on your bench, that is easy. If it is thousands of miles away well inside other assemblies, that is another issue. I would prefer to err on the side of conservatism. But I am not in a situation where the last penny counts. > >Article: 138849
On Mar 12, 7:30=A0pm, Jacko <jackokr...@gmail.com> wrote: > hi > > 292 LEs fully stripped, no ROM, no RAM no IO pins, 16 bit address, 16 > bit data Bus. Expected 20-30MHz, (36 pins plus power), About 10 MIPS > at 20MHz. > > cheers jacko without any io/ram/rom its kinda useless? and such small soft cores can usually run 200mhz+ in decent FPGA's ;) (150mhz in low cost FPGA's) ok, 292 or <570LE, it's ir-relevant as long as there are no tools to program it, and your forth-xxx whatever isnt useable yet? there are zillions of stack soft-cpu's but i fail to see nice and easy tools todo anything with them.. no compilers some forth xxx things that requires some xxx to be installed on your PC and then do something very awkward and some more to get some code actually executing... and yes I have programmed in Forth many decades ago, think used something called GraphForth for msdos =3D=3D compile_my_forth_to_bin.exe hello.forth > hello.bin if that creates a ready to use bin file to run with your nibz and you have tons of tested libraries.. someone may get interested.. if you have something totally untested, not ready no demos no reference design ? =3D=3D ok ZPU (a stack machine also) has GCC toolchain kind of, but it isnt that small anymore the core despite being advertized as smallest 32 bit core with GCC support 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