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 19 abr, 15:39, whygee <why...@yg.yg> wrote: > Antti.Luk...@googlemail.com wrote: > > The ONLY part that satisfies ALL requirements is: ice65L16 from SiliconBlue > > A SBt employee told me that it is not available very soon (end of year ?). > On top of that, is it 5V-tolerant on enough pins ? > > > Antti > > yg > --http://ygdes.com/http://yasep.org YG brought an important question. The data bus is 8 bit wide and address bus is 12 bit wide. I want to add 4 switches so the count is 24 pins or higher.Article: 139926
Darcio Prestes wrote: > Hey programmable logic seniors! I'm planning to build an Atari VCS > 2600 game cartridge in order to play with my "brand new" console > acquired from ebay. I would like to replace the old fashioned 27C > series EPROM by a programmable device thus cutting board space and > (main reason) merging the bankswitching logic and rom file in a single > device. My requirements are 32k x 8 (64k is a plus) of non volatile > memory and some space to house a couple of FFs and logic gates (simple > equations). My question is: which manufacturer, family and/or device > should I look for? Thanks for sharing your valuable experience with my > hobby project. Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is not faster, the easiest solution would be just a microcontroller with sufficient flash storage, like the STM32 series or the LPC21xx series. Should be fast enough in a small assembler loop to decode an address requests, read the flash location and change the data pins to output. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 139927
Frank Buss <fb@frank-buss.de> wrote:
>Darcio Prestes wrote:
>
>> Hey programmable logic seniors! I'm planning to build an Atari VCS
>> 2600 game cartridge in order to play with my "brand new" console
>> acquired from ebay. I would like to replace the old fashioned 27C
>> series EPROM by a programmable device thus cutting board space and
>> (main reason) merging the bankswitching logic and rom file in a single
>> device. My requirements are 32k x 8 (64k is a plus) of non volatile
>> memory and some space to house a couple of FFs and logic gates (simple
>> equations). My question is: which manufacturer, family and/or device
>> should I look for? Thanks for sharing your valuable experience with my
>> hobby project.
>
>Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is
>not faster, the easiest solution would be just a microcontroller with
>sufficient flash storage, like the STM32 series or the LPC21xx series.
>Should be fast enough in a small assembler loop to decode an address
>requests, read the flash location and change the data pins to output.
I think that will actually work. IIRC the old Motorola controllers use
an extra E signal to distingiush between the address selection and
data cycle. But you'll need the LPC2000 series with fast I/O and they
are fully 5V tolerant. The ST peripherals are crap.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 139928On Sun, 19 Apr 2009 21:35:12 +0200, whygee <whygee@yg.yg> wrote: >Hi ! > >Brian Drummond wrote: >> On Sun, 19 Apr 2009 03:08:39 +0200, whygee <whygee@yg.yg> wrote: >>> Brian Drummond wrote: >>>> The other crystal is 12.288MHz then. >>> good guess :-) >Yes I have changed my mind again, with the help of yet another trick : >44100 and 48000 have 300 as common divisor >(and I need 256 times this frequency). (44100/300)*(48000/300)=23520 >I'll have to divide this by 149 or 160 to obtain the right frequency. Sorry, I'd forgotten that one. It's 147 not 149, or 7*7*3 if you are restricted in ratios... versus 8*5*4 for 48kHz. >The Actel PLL has only 7-bit ratios, that is too short >(128<147). (Unless you can use their factors as above. Which means 2 PLLs. >Now I have to find a frequency in the 5-15 MHz range that satisfies >all these division needs and PLL osc. ranges. 7.056 MHz sound about right? :-) >Maybe I'll be able to solve this with 2 PLLs or another trick ? The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to find a high frequency (but less than 1.8G) that you can divide down to close approximations to both 12.288 and 11.2896. (I had a program to search for these once...) Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but substantially no jitter at the sample rate) use a 200-300MHz osc (standard freq, standard module) and a phase accumulator to generate 11/12Mhz. This will be arbitrarily accurate and reloading the phase increment will switch frequency without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc. >that's interesting, though my concern is more about long-term stability. >150ppm of drift can add up to a significant delay after a while, >which will desynchronise the system... Long term drift would be at least an order of magnitude less; the pull was because one mode of operation required a PLL round the crystal to synchronise to other equipment. - BrianArticle: 139929
Hello Friends I am a new techie on FPGA I am dumping simple programs <4 bit on Xilinx Spartan-3E kit with xilinx ISE can any one say me how to dumb a program >4bit on this kit and please say me why micro biz is used Thanking you Ramesh -- ramesh441 ------------------------------------------------------------------------ ramesh441's Profile: http://www.fpgacentral.com/group/member.php?userid=69 View this thread: http://www.fpgacentral.com/group/showthread.php?t=89534Article: 139930
On 2009-04-18, mooo <randomname650@gmail.com> wrote: > I don't know, this is my third verilog program and I'm just tooling > around on my lonesome in my spare time. I was googling around trying > to figure out how to convert a binary number to an ASCII string and > that's what I came up with. How does one tell whether or not > something is synthesizeable? This is what's wrong with almost every Verilog tutorial I've seen. They all start out teaching you about the scripting features of Verilog (which are not synthesizable) and totally fail to make the distinction. What's worse is that most people using those tutorials are software programmers who are easily misled. I would scale back your first attempt to sending an ASCII binary string out your serial port. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 139931
Brian Drummond wrote: > On Sun, 19 Apr 2009 21:35:12 +0200, whygee <whygee@yg.yg> wrote: >> Yes I have changed my mind again, with the help of yet another trick : >> 44100 and 48000 have 300 as common divisor >> (and I need 256 times this frequency). (44100/300)*(48000/300)=23520 >> I'll have to divide this by 149 or 160 to obtain the right frequency. > Sorry, I'd forgotten that one. > It's 147 not 149, or 7*7*3 if you are restricted in ratios... sorry for the type :-) > versus 8*5*4 for 48kHz. yes, I wrote them all down... IIRC the 44100Hz sampling rate comes from a storage medium that used video tapes, they simply reused the same sampling rate when they designed the CD standard, because there was no other digital recording equipment that could match the CD quality... So one should find television frequencies, divisors or factors, no ? >> The Actel PLL has only 7-bit ratios, that is too short (128<147). > (Unless you can use their factors as above. Which means 2 PLLs. I'll look at the recent "Igloo plus" or "Igloo E" that have 2 to 6 PLLs. Currently (for my first custom board) I keep the usual ProASIC3, cheaper, available and more-or-less compatible with the successors. >> Now I have to find a frequency in the 5-15 MHz range that satisfies >> all these division needs and PLL osc. ranges. > 7.056 MHz sound about right? :-) sure :-) I've seen this frequency when playing with the ratios, but i did not settle there because I needed another *256 factor. I'll look more closely to this one... >> Maybe I'll be able to solve this with 2 PLLs or another trick ? > The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to > find a high frequency (but less than 1.8G) that you can divide down to close > approximations to both 12.288 and 11.2896. (I had a program to search for these > once...) hmmm... If I was OK then I would not bother and use Wolfson or Texas Instruments chips, they generate "something close enough to the required frequency" from a 12MHz quartz (that is required by the USB protocol). I'm not an "audiophile" but I know digital sound enough to know how to avoid stupid problems later (even when it means that I have to solve not-so-easy problems now). > Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but > substantially no jitter at the sample rate) yes because it is integrated by the *256 oversampling D/A (and hopefully a PLL ?) > use a 200-300MHz osc (standard freq, > standard module) and a phase accumulator to generate 11/12Mhz. It's going to buuuuurn power :-/ > This will be > arbitrarily accurate and reloading the phase increment will switch frequency > without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc. hmmm... I prefer the PLL idea because it uses special gates, not those from the fabric. And a phase accumulator needs to work at high speed, but a standard 32-bit adder in ProASIC3 works generally at 60-70MHz max. And it eats quite a lot of gates. thank you for the insight, > - Brian yg -- http://ygdes.com / http://yasep.orgArticle: 139932
Antti.Lukats@googlemail.com wrote: > 1) Actel PLL tolerates customer xx.yy divider clock remover in the > feedback loop, so it can generate almost any frequency - see "pll > clock dither app note" I've not heard about it yet... I'll have to find it. > 2) there is dynamic config mode yes, I count on this one too :-) I'll modify my SPI master VHDL code to include the 81-bit shift register thing. > so you can connect ext freq to 1 pin, and get all the desired > frequencies from single PLL > > PS for the clock dither you NEED specific extfb path connecting 2 > actual IOs of the FPGA, on PA it was possible in fabric but PA3 > requires external loopback, this loopback wire is one of the things we > added on FPGA stamp PCB rev B, just to support the clock dither trick thanks for the tips ! > Antti yg -- http://ygdes.com / http://yasep.orgArticle: 139933
On Apr 20, 2:11=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Sun, 19 Apr 2009 21:35:12 +0200, whygee <why...@yg.yg> wrote: > >Hi ! > > >Brian Drummond wrote: > >> On Sun, 19 Apr 2009 03:08:39 +0200, whygee <why...@yg.yg> wrote: > >>> Brian Drummond wrote: > >>>> The other crystal is 12.288MHz then. > >>> good guess :-) > >Yes I have changed my mind again, with the help of yet another trick : > >44100 and 48000 have 300 as common divisor > >(and I need 256 times this frequency). (44100/300)*(48000/300)=3D23520 > >I'll have to divide this by 149 or 160 to obtain the right frequency. > > Sorry, I'd forgotten that one. > It's 147 not 149, or 7*7*3 if you are restricted in ratios... > versus 8*5*4 for 48kHz. > > >The Actel PLL has only 7-bit ratios, that is too short > >(128<147). > > (Unless you can use their factors as above. Which means 2 PLLs. > > >Now I have to find a frequency in the 5-15 MHz range that satisfies > >all these division needs and PLL osc. ranges. > > 7.056 MHz sound about right? :-) > > >Maybe I'll be able to solve this with 2 PLLs or another trick ? > > The alternative - if you can tolerate a tiny (1-10ppm) frequency error - = is to > find a high frequency (but less than 1.8G) that you can divide down to cl= ose > approximations to both 12.288 and 11.2896. (I had a program to search for= these > once...) > > Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but > substantially no jitter at the sample rate) use a 200-300MHz osc (standar= d freq, > standard module) and a phase accumulator to generate 11/12Mhz. This will = be > arbitrarily accurate and reloading the phase increment will switch freque= ncy > without glitches. Jitter will be 1 (optionally 1/2) cycle of the fast osc= . > > >that's interesting, though my concern is more about long-term stability. > >150ppm of drift can add up to a significant delay after a while, > >which will desynchronise the system... > > Long term drift would be at least an order of magnitude less; the pull wa= s > because one mode of operation required a PLL round the crystal to synchro= nise to > other equipment. > > - Brian 1) Actel PLL tolerates customer xx.yy divider clock remover in the feedback loop, so it can generate almost any frequency - see "pll clock dither app note" 2) there is dynamic config mode so you can connect ext freq to 1 pin, and get all the desired frequencies from single PLL PS for the clock dither you NEED specific extfb path connecting 2 actual IOs of the FPGA, on PA it was possible in fabric but PA3 requires external loopback, this loopback wire is one of the things we added on FPGA stamp PCB rev B, just to support the clock dither trick AnttiArticle: 139934
whygee <whygee@yg.yg> wrote: > IIRC the 44100Hz sampling rate comes from a storage medium that used > video tapes, they simply reused the same sampling rate when they designed > the CD standard, because there was no other digital recording equipment > that could match the CD quality... So one should find television > frequencies, divisors or factors, no ? If I remember the story, it was also so that the video tape based system could be used to store master tapes for CDs. My first hard disk, a few years after CDs came out, was 40MB. Tape was the only medium with enough storage capacity for a CD master. -- glenArticle: 139935
On 19 avr, 22:33, Frank Buss <f...@frank-buss.de> wrote: > Darcio Prestes wrote: > > Hey programmable logic seniors! I'm planning to build an Atari VCS > > 2600 game cartridge in order to play with my "brand new" console > > acquired from ebay. I would like to replace the old fashioned 27C > > series EPROM by a programmable device thus cutting board space and > > (main reason) merging the bankswitching logic and rom file in a single > > device. My requirements are 32k x 8 (64k is a plus) of non volatile > > memory and some space to house a couple of FFs and logic gates (simple > > equations). My question is: which manufacturer, family and/or device > > should I look for? Thanks for sharing your valuable experience with my > > hobby project. > > Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is > not faster, the easiest solution would be just a microcontroller with > sufficient flash storage, like the STM32 series or the LPC21xx series. > Should be fast enough in a small assembler loop to decode an address > requests, read the flash location and change the data pins to output. > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de IMO, there are some issues that prevent from doing that : - Some cartridges have werid bankswitching schemes, some others contain additional RAM, so even at 50Mhz or so, your assembler loop may not fit in a VCS clock cycle. And for the LPC2xxx series, even the ones with "fast I/O" can't switch over 15-16Mhz, IIRC. - VCS2600 has not reset switch (the reset switch on the front panel doesn't perform a reset of the machine), and the power-on reset delay is very small. Your MCU might not have the time to perform its own initialization code. Well, in this case you could still use a separate power supply.Article: 139936
Hello, For those who just got their hands on an Igloo nano Starter Kit, and especially for beginners, I have assembled a complete Tutorial at : http://www.alse-fr.com/Actel/igloo.html Enjoy... BertArticle: 139937
On Mon, 20 Apr 2009 07:30:16 +0200, whygee <whygee@yg.yg> wrote: >Brian Drummond wrote: >> On Sun, 19 Apr 2009 21:35:12 +0200, whygee <whygee@yg.yg> wrote: >>> Yes I have changed my mind again, with the help of yet another trick : >>> 44100 and 48000 have 300 as common divisor >>> (and I need 256 times this frequency). (44100/300)*(48000/300)=23520 >>> I'll have to divide this by 149 or 160 to obtain the right frequency. >> Sorry, I'd forgotten that one. >> It's 147 not 149, or 7*7*3 if you are restricted in ratios... >sorry for the type :-) > >> versus 8*5*4 for 48kHz. >yes, I wrote them all down... > >IIRC the 44100Hz sampling rate comes from a storage medium that used >video tapes, they simply reused the same sampling rate when they designed >the CD standard, because there was no other digital recording equipment >that could match the CD quality... So one should find television >frequencies, divisors or factors, no ? > >>> The Actel PLL has only 7-bit ratios, that is too short (128<147). >> (Unless you can use their factors as above. Which means 2 PLLs. >I'll look at the recent "Igloo plus" or "Igloo E" that have 2 to 6 PLLs. >Currently (for my first custom board) I keep the usual ProASIC3, >cheaper, available and more-or-less compatible with the successors. > > >>> Now I have to find a frequency in the 5-15 MHz range that satisfies >>> all these division needs and PLL osc. ranges. >> 7.056 MHz sound about right? :-) >sure :-) >I've seen this frequency when playing with the ratios, >but i did not settle there because I needed another *256 factor. >I'll look more closely to this one... > >>> Maybe I'll be able to solve this with 2 PLLs or another trick ? >> The alternative - if you can tolerate a tiny (1-10ppm) frequency error - is to >> find a high frequency (but less than 1.8G) that you can divide down to close >> approximations to both 12.288 and 11.2896. (I had a program to search for these >> once...) >hmmm... >If I was OK then I would not bother and use Wolfson or Texas Instruments >chips, they generate "something close enough to the required frequency" >from a 12MHz quartz (that is required by the USB protocol). >I'm not an "audiophile" but I know digital sound enough to know how >to avoid stupid problems later (even when it means that I have to solve >not-so-easy problems now). > >> Or if you can live with say 3-5ns jitter on the 11/12MHz clock (but >> substantially no jitter at the sample rate) >yes because it is integrated by the *256 oversampling D/A >(and hopefully a PLL ?) With an oversampling D/A you want the lowest possible jitter on the *256 clock; the phase accumulator (unless followed by a PLL) is not a good option. You need identical area under all 256 possible charge packets. Given that constraint the PLL looks better. However it might be worth asking where you get the D/A. If you can roll your own - or even the DSP portion and use the analog portion of a commercial solution - it would be possible to oversample by either *3,*7,*7 or *4,*5,*8 and generate both datastreams at the same clock frequency. But that would require a medium sized Spartan-3 or equivalent; possibly bigger than you want. - BrianArticle: 139938
On Mon, 20 Apr 2009 05:53:39 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >whygee <whygee@yg.yg> wrote: > >> IIRC the 44100Hz sampling rate comes from a storage medium that used >> video tapes, they simply reused the same sampling rate when they designed >> the CD standard, because there was no other digital recording equipment >> that could match the CD quality... So one should find television >> frequencies, divisors or factors, no ? > >If I remember the story, it was also so that the video tape >based system could be used to store master tapes for CDs. > >My first hard disk, a few years after CDs came out, >was 40MB. Tape was the only medium with enough storage >capacity for a CD master. Specifically the Sony U-Matic semi-pro (3/4 inch?) videotape used by the PCM1600 (1610?). Three samples (per channel) per active line on either 60Hz NTSC or 50Hz PAL. Since drop-frame NTSC actually ran at 59.94Hz (I believe to hide supply interference) the American version actually sampled at 44.056 kHz. But I don't believe any CD players actually followed that particular deviation. - BrianArticle: 139939
Gregory Estrade wrote: > IMO, there are some issues that prevent from doing that : > - Some cartridges have werid bankswitching schemes, some others > contain additional RAM, so even at 50Mhz or so, your assembler loop > may not fit in a VCS clock cycle. And for the LPC2xxx series, even the > ones with "fast I/O" can't switch over 15-16Mhz, IIRC. You are right, this could be interesting. The bankswitching I've found doesn't look complicated: http://www.scribd.com/doc/5439358 It is just a read from a magic address to switch banks. Simulating 256 bytes RAM works by providing write access from 0x1000 to 0x10ff and read access for the same memory by accessing 0x1100 to 0x11ff. But the E7 method might be a bit more complicated. So I think the standard catridge with a 4k eprom simulation should be no problem. If there are problems with the 3.3V output of the microcontroller (might be not enough voltage for the data out), you'll need additional level translation chips. A PIC might be better, e.g. the PIC18F2420, which works with 5V power supply and up to 40MHz. But you have to carefully read the timing diagrams of the Atari system and the PIC and check if it is possible to implement the more complex bank switching concepts. Each port write and read of the PIC needs already 8 clocks, so might be too slow. > - VCS2600 has not reset switch (the reset switch on the front panel > doesn't perform a reset of the machine), and the power-on reset delay > is very small. Your MCU might not have the time to perform its own > initialization code. Well, in this case you could still use a separate > power supply. At least the schematic for the Junior version shows a reset circuit with a 12k resistor loading a 4u7 elco: http://www.atariage.com/2600/archives/schematics_pal/Schematic_2600_Junior_PAL.html The original schematic looks a bit strange, because I don't see any plus supply to the reset pin: http://www.atariage.com/2600/archives/schematics_pal/Schematic_2600_Console_PAL.html But I guess this was just missing from the schematic, and it was something like 1k for loading the 4u7, which should give a lot of time to start a microcontroller from the same power supply. So a FPGA with serial configuration might be too slow, but you could buffer it with an elco and just power cycle the Atari twice, or changing the reset circuit inside the Atari system. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 139940
On Sun, 19 Apr 2009 22:33:00 +0200, Frank Buss <fb@frank-buss.de> wrote: >Darcio Prestes wrote: > >> Hey programmable logic seniors! I'm planning to build an Atari VCS >> 2600 game cartridge in order to play with my "brand new" console >> acquired from ebay. I would like to replace the old fashioned 27C >> series EPROM by a programmable device thus cutting board space and >> (main reason) merging the bankswitching logic and rom file in a single >> device. My requirements are 32k x 8 (64k is a plus) of non volatile >> memory and some space to house a couple of FFs and logic gates (simple >> equations). My question is: which manufacturer, family and/or device >> should I look for? Thanks for sharing your valuable experience with my >> hobby project. > >Wikipedia says that the VCS 2600 has a 6507 with 1.19 MHz. So if the bus is >not faster, the easiest solution would be just a microcontroller with >sufficient flash storage, like the STM32 series or the LPC21xx series. >Should be fast enough in a small assembler loop to decode an address >requests, read the flash location and change the data pins to output. With ARM MCUs with fast IO like the NXP LPC series, you can use FIQs on the chip select to give very fast response to external signals - I've read data from an image sensor at 4MHz like this in the past. The only problem is that to get enough on-chip RAM you end up paying for a lot of flash you don't need - and external SRAM usually works out cheaper. However a CPLD plus SRAM may end up being the cheapest overall solution.Article: 139941
Brian Drummond <brian_drummond@btconnect.com> wrote: (snip, I wrote) >>If I remember the story, it was also so that the video tape >>based system could be used to store master tapes for CDs. >>My first hard disk, a few years after CDs came out, >>was 40MB. Tape was the only medium with enough storage >>capacity for a CD master. > Specifically the Sony U-Matic semi-pro (3/4 inch?) videotape > used by the PCM1600 (1610?). Three samples (per channel) > per active line on either 60Hz NTSC or 50Hz PAL. > Since drop-frame NTSC actually ran at 59.94Hz (I believe > to hide supply interference) the American version actually > sampled at 44.056 kHz. It comes from three constraints, the last one being the offset between the video and the audio subcarrier. The first two are an odd number of cycles per line and per field. > But I don't believe any CD players actually followed that > particular deviation. Well, for NTSC timing, the 59.94 only applies to color signals (with an active color burst). Black and white signals would still run at 60Hz. In either case, the recorder has to synch to the incoming signal. Normally (for TV sets) in playback, one would synch to the playback signal. I believe that some players would allow one to supply a source signal for the player to synch to. That would allow, for example, combining two video signals. -- glenArticle: 139942
On Apr 19, 2:13=A0pm, whygee <why...@yg.yg> wrote: > -jg wrote: > [snip] > Off-topic : what FPGA family provides an internally-generated /RESET sign= al > to the logic array ? Those that I know require an externel signal... > Now that I think about this, it sounds curious. > This is probably because most chips work with different I/O-cores-whateve= r voltages, > but then in a Flash-based FPGA at least, one could eventually program > the tripping voltage of a power supply supervisor. > I guess that the Fusion devices are a bit close to this, but the chip > can examine its own power supply with the ADC which means that the core > must be initialised before... > > > -jg > > yg > > --http://ygdes.com/http://yasep.org Pretty much all SRAM-based FPGA's have internal power-on reset circuitry to trigger the configuration of the part. While this reset happens well before the logic is up and running, the nature of the bitstream load lends itself to an internal reset in that all of the flip-flops and (usually) RAM cells are initialized during configuration. An internal reset can be generated simply by releasing the logic to a running state. The normal procedure is to instantiate a short shift register with an initial value of all 1's (or all 0's for active low logic) and then shifting in 0's when the chip starts up. The output of the shift register will therefore start up the rest of the chip a few clocks after configuration is complete without the need for an external reset signal. Regards, GaborArticle: 139943
On Apr 20, 12:52=A0am, Ben Jackson <b...@ben.com> wrote: > On 2009-04-18, mooo <randomname...@gmail.com> wrote: > > > I don't know, this is my third verilog program and I'm just tooling > > around on my lonesome in my spare time. =A0I was googling around trying > > to figure out how to convert a binary number to an ASCII string and > > that's what I came up with. =A0How does one tell whether or not > > something is synthesizeable? > > This is what's wrong with almost every Verilog tutorial I've seen. =A0The= y > all start out teaching you about the scripting features of Verilog (which > are not synthesizable) and totally fail to make the distinction. =A0What'= s > worse is that most people using those tutorials are software programmers > who are easily misled. > > I would scale back your first attempt to sending an ASCII binary string > out your serial port. > > -- > Ben Jackson AD7GD > <b...@ben.com>http://www.ben.com/ Not a bad suggestion, since it skips the binary to decimal step. Printing a hexadecimal string would not be much harder. Cheers, GaborArticle: 139944
Hi, I've downloaded ISE 10.1 and I'm now trying to install it on my PC. Every time I click on setup.exe, the program crashes and I get an error message from Windows. I tried running it as an administrator, I tried running it with "windows xp compatability mode" and it still doesn't work. What's weird is that I've installed ISE 9.2 without any problems. It seems that Vista home is not officially supported by Xilinx since they only mention Vista Business on ISE 10.1 webpage. However, it should stil work with Vista Home. My windows vista configuration is the following : Windows Vista Home edition premium 32-bit French 3 gig of ram Best regardsArticle: 139945
On Apr 19, 10:10 am, jleslie48 <j...@jonathanleslie.com> wrote:
> On Apr 19, 9:06 am, Brian Drummond <brian_drumm...@btconnect.com>
> wrote:
>
>
>
> > On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <j...@jonathanleslie.com>
> > wrote:
>
> > >> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide)
> > >> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock
> > >> the actual logic off 40MHz. This will ensure the tool's timing analysis works
> > >> correctly and eliminates a major potential set of problems; it may waste a few
> > >> mw if that matters.
>
> > >> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG
> > >> output should be automatically routed on low skew networks and analyzed for
> > >> timing hazards.
> > >Thanks for the tips. they will be tried/looked at on monday morning.
> > >I am confused though. what's the big deal about it being a "clock"?
>
> > For all other signals, the tools basically only need to guarantee the routing is
> > faster than the clock period (+/- small allowance for jitter, clock skew etc);
> > which at 4Hz or even 40MHz is easy.
>
> > For a clock, the tools must perform a much more rigorous analysis; it is equally
> > bad for a clock signal to arrive too early as too late!
>
> > I presume your 4Hz clock is driving a simple state machine to blink blink blink;
> > pause; repeat.
>
> > If the clock delay to each FF in that SM isn't tightly controlled, it will reach
> > some FFs before their inputs change, and others after their inputs (output from
> > FFs clocked earlier) change. Hence there is no predicting what the SM will do.
> > And each routing pass will behave differently; by chance, some may even work!
>
> > >I don't get why tying a std_logic value to a second output pin can be
> > >a catalyst to a catastrophic failure of an FPGA.
>
> > That can cause the routing to change significantly.
>
> > Don't let it scare you - once you find the groove; avoiding dodgy design areas -
> > the tools will deliver reliable results. It's not any worse than C's pointer
> > arithmetic!
>
> > Re: persistence of obsolete pins: how are you generating constraints (UCF
> > files)?
>
> > If you are using the ISE tools, it's worth checking the UCF file in a text
> > editor; I just use the editor and forget the tools (which maddeningly force
> > another synthesis pass first because I updated a comment somewhere)
>
> > I also check the translate (.bld) report, the map (.mrp) report and the PAR
> > (.par) report; if any of these stages fail, you CAN end up using obsolete files
> > (at least from the command line)
>
> > - Brian
>
> Yeah, I only use the UCF file in the text editor. I'll take a look at
> all those files very
> carefully. I tried doing a diff at one point between a working
> version using pin 15 and an non
> working version using pin13 but nothing jumped up at me. On several
> occasions I just went into
> the ucf file with notepad, added a trailing space and saved just to
> make sure it was touched, Didn't help though.
Ok, I'm looking at the PACE and pinout report, nothing jumps out at
me, maybe you can see something.
Here's the program that drives the LED, and pins 17, 18. This one
works fine:
http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap24_led3_working_pins_1718.png
and heres the one where all I did was add PIN15_LED, but it locks up
the FPGA:
http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap25_led3_notworking_pins_1718_15.png
I hi-lighted/ red-boxed what appears to me to be the significant
lines.
It just doesn't make any sense.
the UCF file differs by one line, I added:
NET "PIN15_led" LOC = "A13"; #"FPGA_IO14"
and the top.vhd differs by two,
I've added the pin15_led line here:
-----------------------------------------------------------------------
ENTITY lprj_TOP IS
Port
(
-- CLOCKS.UCF SIGNALS
SYSTEM_CLOCK : IN STD_LOGIC;
-- RS232.UCF SIGNALS
RS232_DSR_OUT : OUT STD_LOGIC;
HUART_TX_LINE : OUT STD_LOGIC;
RS232_CTS_OUT : OUT STD_LOGIC;
HUART_RX_LINE : IN STD_LOGIC;
--RS232_RTS_IN : IN STD_LOGIC;
-- SIGNALS
a2mhz_HUART_TX_LINE : OUT STD_logic;
a2mhz_HUART_CK_LINE : OUT STD_LOGIC;
-- LEDS.UCF SIGNALS
led_2 : OUT STD_LOGIC;
led_3 : OUT STD_LOGIC;
led_4 : OUT STD_LOGIC;
led_5 : OUT STD_LOGIC;
pin15_led : OUT STD_LOGIC;
-- FPGA pin JTAG signals -- dummy placeholders.
-- TCK : IN STD_LOGIC;
-- TDI : IN STD_LOGIC;
-- TDO : in STD_LOGIC;
-- TMS : IN STD_LOGIC;
-- jtag_or_dummy : OUT STD_LOGIC;
-- PUSHBUTTON.UCF SIGNALS
button_1 : IN STD_LOGIC;
--PB_UP : IN STD_LOGIC;
PB_DOWN : IN STD_LOGIC;
button_2 : IN STD_LOGIC;
PB_RIGHT : IN STD_LOGIC
);
-----------------------------------------------------------------------
and in the main body of the behavioral I added this pin15_led line:
-----------------------------------------------------------------------
led_3 <= clk_4hz;
pin15_led <= not clk_4hz; -- default state for pin 15 is on.
-----------------------------------------------------------------------
Sincerely,
Jonathan
Leslie
Article: 139946
On Apr 20, 11:46 am, jleslie48 <j...@jonathanleslie.com> wrote:
> On Apr 19, 10:10 am, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Apr 19, 9:06 am, Brian Drummond <brian_drumm...@btconnect.com>
> > wrote:
>
> > > On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <j...@jonathanleslie.com>
> > > wrote:
>
> > > >> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide)
> > > >> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock
> > > >> the actual logic off 40MHz. This will ensure the tool's timing analysis works
> > > >> correctly and eliminates a major potential set of problems; it may waste a few
> > > >> mw if that matters.
>
> > > >> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG
> > > >> output should be automatically routed on low skew networks and analyzed for
> > > >> timing hazards.
> > > >Thanks for the tips. they will be tried/looked at on monday morning.
> > > >I am confused though. what's the big deal about it being a "clock"?
>
> > > For all other signals, the tools basically only need to guarantee the routing is
> > > faster than the clock period (+/- small allowance for jitter, clock skew etc);
> > > which at 4Hz or even 40MHz is easy.
>
> > > For a clock, the tools must perform a much more rigorous analysis; it is equally
> > > bad for a clock signal to arrive too early as too late!
>
> > > I presume your 4Hz clock is driving a simple state machine to blink blink blink;
> > > pause; repeat.
>
> > > If the clock delay to each FF in that SM isn't tightly controlled, it will reach
> > > some FFs before their inputs change, and others after their inputs (output from
> > > FFs clocked earlier) change. Hence there is no predicting what the SM will do.
> > > And each routing pass will behave differently; by chance, some may even work!
>
> > > >I don't get why tying a std_logic value to a second output pin can be
> > > >a catalyst to a catastrophic failure of an FPGA.
>
> > > That can cause the routing to change significantly.
>
> > > Don't let it scare you - once you find the groove; avoiding dodgy design areas -
> > > the tools will deliver reliable results. It's not any worse than C's pointer
> > > arithmetic!
>
> > > Re: persistence of obsolete pins: how are you generating constraints (UCF
> > > files)?
>
> > > If you are using the ISE tools, it's worth checking the UCF file in a text
> > > editor; I just use the editor and forget the tools (which maddeningly force
> > > another synthesis pass first because I updated a comment somewhere)
>
> > > I also check the translate (.bld) report, the map (.mrp) report and the PAR
> > > (.par) report; if any of these stages fail, you CAN end up using obsolete files
> > > (at least from the command line)
>
> > > - Brian
>
> > Yeah, I only use the UCF file in the text editor. I'll take a look at
> > all those files very
> > carefully. I tried doing a diff at one point between a working
> > version using pin 15 and an non
> > working version using pin13 but nothing jumped up at me. On several
> > occasions I just went into
> > the ucf file with notepad, added a trailing space and saved just to
> > make sure it was touched, Didn't help though.
>
> Ok, I'm looking at the PACE and pinout report, nothing jumps out at
> me, maybe you can see something.
>
> Here's the program that drives the LED, and pins 17, 18. This one
> works fine:
>
> http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> and heres the one where all I did was add PIN15_LED, but it locks up
> the FPGA:
>
> http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> I hi-lighted/ red-boxed what appears to me to be the significant
> lines.
>
> It just doesn't make any sense.
>
> the UCF file differs by one line, I added:
>
> NET "PIN15_led" LOC = "A13"; #"FPGA_IO14"
>
> and the top.vhd differs by two,
>
> I've added the pin15_led line here:
>
> -----------------------------------------------------------------------
> ENTITY lprj_TOP IS
>
> Port
>
> (
>
> -- CLOCKS.UCF SIGNALS
> SYSTEM_CLOCK : IN STD_LOGIC;
>
> -- RS232.UCF SIGNALS
> RS232_DSR_OUT : OUT STD_LOGIC;
> HUART_TX_LINE : OUT STD_LOGIC;
> RS232_CTS_OUT : OUT STD_LOGIC;
> HUART_RX_LINE : IN STD_LOGIC;
> --RS232_RTS_IN : IN STD_LOGIC;
>
> -- SIGNALS
> a2mhz_HUART_TX_LINE : OUT STD_logic;
> a2mhz_HUART_CK_LINE : OUT STD_LOGIC;
>
> -- LEDS.UCF SIGNALS
> led_2 : OUT STD_LOGIC;
> led_3 : OUT STD_LOGIC;
> led_4 : OUT STD_LOGIC;
> led_5 : OUT STD_LOGIC;
> pin15_led : OUT STD_LOGIC;
>
> -- FPGA pin JTAG signals -- dummy placeholders.
> -- TCK : IN STD_LOGIC;
> -- TDI : IN STD_LOGIC;
> -- TDO : in STD_LOGIC;
> -- TMS : IN STD_LOGIC;
> -- jtag_or_dummy : OUT STD_LOGIC;
>
> -- PUSHBUTTON.UCF SIGNALS
> button_1 : IN STD_LOGIC;
> --PB_UP : IN STD_LOGIC;
> PB_DOWN : IN STD_LOGIC;
> button_2 : IN STD_LOGIC;
> PB_RIGHT : IN STD_LOGIC
>
> );
> -----------------------------------------------------------------------
>
> and in the main body of the behavioral I added this pin15_led line:
>
> -----------------------------------------------------------------------
> led_3 <= clk_4hz;
> pin15_led <= not clk_4hz; -- default state for pin 15 is on.
>
> -----------------------------------------------------------------------
>
> Sincerely,
>
> Jonathan
> Leslie
here's another view of some stuff, looks neat, does it show anything
of the problem?
http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap26_led3_notworking_pin_15_view.png
Here's the report that is only partially visible:
--------------------------------------------------------------------------------
Release 10.1.03 Trace (nt)
Copyright (c) 1995-2008 Xilinx, Inc. All rights reserved.
C:\Xilinx\10.1\ISE\bin\nt\unwrapped\trce.exe -ise
C:/jon/fpga_uartjl_01/r-drigmorn1/Pchu_cc02/ms_d03/ms_d03.ise -
intstyle ise -v
3 -s 4 -xml lprj_TOP lprj_TOP.ncd -o lprj_TOP.twr lprj_TOP.pcf -ucf
C:/jon/fpga_uartjl_01/r-drigmorn1/Pchu_cc02/ms_d03/source/ucf/
DRIGMORN1.ucf
Design file: lprj_TOP.ncd
Physical constraint file: lprj_TOP.pcf
Device,speed: xc3s500e,-4 (PRODUCTION 1.27 2008-01-09)
Report level: verbose report
Environment Variable Effect
-------------------- ------
NONE No environment variables were set
--------------------------------------------------------------------------------
INFO:Timing:2698 - No timing constraints found, doing default
enumeration.
INFO:Timing:2752 - To get complete path coverage, use the
unconstrained paths
option. All paths that are not constrained will be reported in the
unconstrained paths section(s) of the report.
INFO:Timing:3339 - The clock-to-out numbers in this timing report are
based on
a 50 Ohm transmission line loading model. For the details of this
model,
and for more information on accounting for different loading
conditions,
please see the device datasheet.
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Setup/Hold to clock SYSTEM_CLOCK
-------------+------------+------------+------------------+--------+
| Setup to | Hold to | | Clock |
Source | clk (edge) | clk (edge) |Internal Clock(s) | Phase |
-------------+------------+------------+------------------+--------+
HUART_RX_LINE| 3.122(R)| 0.430(R)|SYSTEM_CLOCK_BUFGP| 0.000|
PB_RIGHT | 7.180(R)| 0.479(R)|SYSTEM_CLOCK_BUFGP| 0.000|
button_1 | 1.756(R)| -0.118(R)|SYSTEM_CLOCK_BUFGP| 0.000|
button_2 | 8.952(R)| 0.424(R)|SYSTEM_CLOCK_BUFGP| 0.000|
-------------+------------+------------+------------------+--------+
Clock SYSTEM_CLOCK to Pad
-------------------+------------+------------------+--------+
| clk (edge) | | Clock |
Destination | to PAD |Internal Clock(s) | Phase |
-------------------+------------+------------------+--------+
HUART_TX_LINE | 9.086(R)|SYSTEM_CLOCK_BUFGP| 0.000|
a2mhz_HUART_CK_LINE| 7.697(R)|SYSTEM_CLOCK_BUFGP| 0.000|
a2mhz_HUART_TX_LINE| 6.159(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_2 | 8.511(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_3 | 9.097(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_4 | 9.246(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_5 | 6.159(R)|SYSTEM_CLOCK_BUFGP| 0.000|
pin15_led | 11.171(R)|SYSTEM_CLOCK_BUFGP| 0.000|
-------------------+------------+------------------+--------+
Clock to Setup on destination clock SYSTEM_CLOCK
---------------+---------+---------+---------+---------+
| Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
SYSTEM_CLOCK | 10.491| | | |
---------------+---------+---------+---------+---------+
Analysis completed Mon Apr 20 10:50:56 2009
--------------------------------------------------------------------------------
Peak Memory Usage: 119 MB
Article: 139947jleslie48 <jon@jonathanleslie.com> wrote: > Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no > problem, but if I drive them at 4hz, they lock up the fpga. Can you define what you mean by 'lock up'? That has a specific meaning for CMOS circuits, though it isn't supposed to happen anymore. Even so, there might still be some conditions where you could get the chip to do it. -- glenArticle: 139948
Benjamin Couillard <benjamin.couillard@gmail.com> wrote: > Hi, I've downloaded ISE 10.1 and I'm now trying to install it on my > PC. Every time I click on setup.exe, the program crashes and I get an > error message from Windows. It would help to tell what the message says. -- glenArticle: 139949
On Apr 20, 1:16 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> jleslie48 <j...@jonathanleslie.com> wrote:
> > Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no
> > problem, but if I drive them at 4hz, they lock up the fpga.
>
> Can you define what you mean by 'lock up'?
>
> That has a specific meaning for CMOS circuits, though it
> isn't supposed to happen anymore. Even so, there might
> still be some conditions where you could get the chip
> to do it.
>
> -- glen
yes, I am not using any formal definition of "lock up"
the symptoms are this:
without pin15_led driven, the program starts up and on LED_3 I see
a blink code that is driven by:
-----------------------------------------------------------------------------------
clock_4hz: PROCESS ( system_clock_used )
BEGIN
IF ( rising_edge(system_clock_used)) then
IF ( clk_4hz_countdown = 0) THEN
clk_4hz_countdown <= human_clock_count;
clk_4hz <= NOT clk_4hz;
else
clk_4hz_countdown <= clk_4hz_countdown -1;
End if; -- countdown ife
END IF;
END PROCESS clock_4hz;
led_3 <= clk_4hz;
-------------------------------------------------------------
when I download the code using the jtag device to the blink code on
the led_3 starts, messages appear on my rs232 port, and all is well.
If I add the line:
----------------------------------------------------
led_3 <= clk_4hz;
pin15_led <= not clk_4hz; -- default state for pin 15 is on.
---------------------------------------------------------
after I download the code using the jtag device, I get a solid light
on the led_3, and none of my messages appear on the RS232 port.
I just went as far as to remove PIN15_led out of the UCF completely,
and let the tools assign it; it still locks up. Its not a hardware
to pin issue.
after the "lock up" I am unable to communicate with the FPGA with the
jtag. Here is the download of the program that locks up the FPGA:
// *** BATCH CMD : Program -p 1
Maximum TCK operating frequency for this device chain: 10000000.
Validating chain...
Boundary-scan chain validated successfully.
'1': Programming device...
PROGRESS_START - Starting Operation.
done.
'1': Reading status register contents...
CRC error : 1
Decryptor security set : 1
DCM locked : 1
DCI matched : 1
legacy input error : 1
status of GTS_CFG_B : 1
status of GWE : 1
status of GHIGH : 1
value of MODE pin M0 : 1
value of MODE pin M1 : 1
value of MODE pin M2 : 1
value of CFG_RDY (INIT_B) : 1
DONEIN input from DONE pin : 1
IDCODE not validated while trying to write FDRI : 1
write FDRI issued before or after decrypt operation: 1
Decryptor keys not used in proper sequence : 1
WARNING:iMPACT:2217 - Error shows in the status register, CRC Error
bit is NOT 0.
INFO:iMPACT:2219 - Status register values:
INFO:iMPACT - 1111 1111 1111 1111 1111 1111 1111 1111
INFO:iMPACT:579 - '1': Completed downloading bit file to device.
INFO:iMPACT - '1': Checking done pin....done.
'1': Programmed successfully.
PROGRESS_END - End Operation.
Elapsed time = 1 sec.
------------------------------------------------------------------------------------------------
Please note the WARNING: iMPACT:2217 - Error shows in the status
register, CRC Error bit is NOT 0.
a subsequent call to 'get device id' yields:
// *** BATCH CMD : ReadIdcode -p 1
INFO:iMPACT:583 - '1': The idcode read from the device does not match
the idcode in the bsdl File.
INFO:iMPACT:1578 - '1': Device IDCODE :
00001111111111111111111111111111
INFO:iMPACT:1579 - '1': Expected IDCODE:
00000001110000100010000010010011
and a big red 'ReadIDcode failed' block pops up in instead of the nice
blue block saying 'succeeded'
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