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
<richard.melikson@gmail.com> wrote in message news:1189507163.594238.209960@r29g2000hsg.googlegroups.com... >> This technique is useful if you access RAM/ROM linearly as a FIFO. Say >> for example a video frame buffer. Using gray code instead of straight >> low to high addressing allows you to stream the data into or out of >> memory without using a latch. > > Could you elaborate on this, please - how does it avoid a latch, and > where does the latch come from anyway in straight addressing ? > R You use the change in address bit to 'register' the data into the memory rather than a write strobe. You can then write once per master clock cycle instead of having to have two cycles the first with the write strobe low, the next high (typically). I thought about trying this on an external SRAM for a project a couple of years ago but couldn't find any data sheets confirming this is a valid way of writing data to an SRAM and did't have time to experiment to test it. NialArticle: 124051
ZHI wrote: (snip) > I prefer to use fixed-point in this FPGA design. What I am doing is to > implement an algorithm which is written in Matlab. I am trying to > implement it into FPGA board. There are some things to be considered. > e.g. EXP function, COS function in Matlab. I know there are the same > functions in VHDL as well. But the result is floating-point. I will presume that the usual tools won't synthesize cos() in VHDL. It isn't hard to do with a table lookup or two. It is easiest if the input is a binary number of revolutions (that is, radians divided by two pi). I have known it done with a lookup table, a linear interpolation table, and an adder. With BRAMs in current FPGAs, one table may be enough. > I can > guarantee the FPGA input numbers are fixed-point numbers. If there > happened the floating-point numbers in the process of caculation.How > to solve it? I want everything in the algorithm is fixed point. I will > firstly simulate the algorithm in Matlab with fixed-point. I did not > think out how to deal with these function results. If possible, keep it in fixed point with the appropriate position for the binary point. I recommend looking at the systolic array architecture, but it depends somewhat on the problem being solved. -- glenArticle: 124052
Yes, I have. They are the same: 3750 ps for 266.67 MHz. I set the clock frequency with the MIG and the clock period in the test bench (constrain CLK_PERIOD) and I measured the clock period in the simulation wave form. DaMicha.Article: 124053
richard.melikson@gmail.com wrote: > Hello, > > Most books on digital design discuss Gray codes. However, most of the > focus is on generating these codes, rather than detailing their uses. > > I read the Wikipedia article: http://en.wikipedia.org/wiki/Gray_code, > but it doesn't provide enough in-depth information of the uses of Gray > code in hardware. > > I know Gray codes are used for: > > 1) Encoding state machine states. Why is it an advantage to use Gray > codes here ? > 2) Async FIFO addressing between clock domains. Could anyone elaborate > on this ? > 3) Error correction in digital communications. Again, I'd love to hear > some more details about this. > > In general, what are the other uses of these codes? When was the last > time you needed Gray codes in your design and for what purpose ? > > R My most recent use: a combinatorial divide-by-8 counter for a clock that might be too fast to go through Flops but able to have predictable timing through three LUTs. I used it as a prescaler for the output of a ring oscillator. Three 4-input LUTs take in one clock and the three values to pass the clock - normal or inverted as necessary - as the active "count up" bit. It was a nifty little application. - John_HArticle: 124054
Peter Really thanx. :)
Do i have to use
"lis r1, 0xa0008001@h" or "lis r1, 0xa0008001@ha"? what is the
difference of them?
Yes it is loading the correct data now. but i would like to ask why it
is loading before the correct data some others before? and why at the
end they become all zeros?. When i am loading the bram with data i
load it like this:
WAIT FOR 40 ns;
dsocm_bram_BRAM_WEN_B_pin <= transport "1111" ;
dsocm_bram_BRAM_Addr_B_pin <= transport
std_logic_VECTOR'("10100000000000001000000000000100"); --1 -- A0008004
-Word 1
dsocm_bram_BRAM_Dout_B_pin <= transport
std_logic_VECTOR'("00000000000000000001000100010001"); --1111
This is, A0008004, the second location form the location range 0-255?
or for the second location of the Bram the address should be :
socm_bram_BRAM_Addr_B_pin <= transport
std_logic_VECTOR'("00000000000000000000000000000010"); --1 --
regards
Article: 124055This file is part of a bigger design which contains the ins and outs to the pins. I did work a lot with modelsim and built the whole timings nicely. Any other ideas? I don't have microblaze, so I can't use it. Can I do sth. with picoblaze?Article: 124056
On Sep 11, 3:14 pm, dami...@gmx.de wrote: > Yes, I have. They are the same: 3750 ps for 266.67 MHz. > I set the clock frequency with the MIG and the clock period in the > test bench (constrain CLK_PERIOD) and I measured the clock period in > the simulation wave form. > > DaMicha. Yes the generated timings are miscomputed ... They forgot to take several thing into account ... You can modify the _parameters.vhd file yourself and change the value. There is only 4 or 5 important ones. To redure the wtp and wr to their minimum I think you'll have to modify the _ddr2_controller.vhd file and force them ... To understant how to compute the delay, look at their state machine and how they use the value you specify. SylvainArticle: 124057
hello all, I'm trying to compile the microblaze-toolchain from source on a 64 bits linux system, but got stuck. The source from the petalogix repository doesn't compile. a first problem was solved with help of colleague: a declaration error in 2 header files of binutils/gas (just wondering if this is done on purpose by petalogix..). Anyhow, compilation proceeded with building of gcc, but it stopped after the first xgcc line after mkinstalldirs libgcc etc. I subsituted as cflag -m32 to force 32 bits cross tools and the build process got a bit further, but still an error. The following line is stopper: _floatdisf.o /usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/xgcc -B/usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/ -B/usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/bin/ -B/usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/lib/ -isystem /usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/include -isystem /usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/. -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/../include -DL_fixunsdfsi -c /usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/libgcc2.c -o libgcc/./_fixunsdfsi.o /tmp/cceNkJta.s: Assembler messages: /tmp/cceNkJta.s:124: Error: operand must be absolute in range -2147483648..2147483647, not -1042284544 make[2]: *** [libgcc/./_fixunsdfsi.o] Error 1 make[2]: Leaving directory `/ usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc Somebody any idea how to solve this? Anybody succesful with building this toolchain with a 64 bit linux system (it's running suse 10.2)? Anybody willing to put a ready-to-run toolchain in a tarball somewhere? TacoArticle: 124058
Hi everyone, I'm a student of the RWTH (or university of) Aachen, Germany. Right now I'm writing my diploma thesis at the Chair of Computer Science "Software for Embedded Systems". With this thesis comes an interactive web application. The idea of this application is that developers of embedded systems get and give informations and help concerning the non-functional requirements of embedded systems. The non-functional requirements are the so-called bilities like reliability, dependability, maintainability and so on. We also call them hardware attributes. Also in the focus of the application are the properties influencing these attributes (like the debug support influences the testability). So for inexperienced developers a question might be: "What is testability and how is it influenced by the debug support and why might it be important for my needs?" But if this developer does not even know about the existence of testability he/she might after visiting the application. Until now I mostly found questions about hard facts or functional requirements like the amount of RAM necessary for an explicit application. Mostly inexperienced developers seem to ask these questions not knowing that there can also be non-functional requirements (like in software-engineering). Right now the application is still a beta version. But I want to invite you to visit the application and give comments and/or expand the attribute-tree. You can find the application on http://diplom.julianwild.de Unfortunately the databaseserver of my provider sometimes is overloaded. Please try again a few minutes later. I thank you for your time (and perhaps your interest?) Julian WildArticle: 124059
Has anyone else encountered the problem of shape and size of M9K blocks (I suppose this applies to other devices also). e.g. if I want a 2720X18 memory (48960 bits), the wizard will construct one out of 9 4096X2 memories (82944 bits) which is 60% efficient. Does anyone have a stategy for getting more efficiency of usage out of these blocks? I can think of one way (in this example by stacking 6 512X18 blocks and using multiplexers and decoders etc.) but perhaps someone has a better or more straightforward approach. I'm asking this about SIII because I am quite used to SII M4K and M512 blocks which seemed to be a better fit for my designs. Thanks, DaveW.Article: 124060
On Sep 11, 4:42 am, David Brown <da...@westcontrol.removethisbit.com> wrote: > Jonathan Kirwan wrote: > > <snip huge and informative post> > > I hope you copied-and-pasted a lot of that post rather than writing it > all yourself! > > I hadn't thought about using Gray code for communication, but it's a > really smart idea. Supposing you want to send 10-bit data within a > 16-bit message. All you need to do to send data "x" is to calculate: > > y = toGray16(x << 6) > > At the other side, you receive "z". To get your best estimate for the > original "x", you calculate: > > x' = (fromGray16(z) + 0x1f) >> 6 > xe = z - (x1' << 6) > > xe is the Hamming distance between the sent data (assuming the > corruption is not too bad, obviously) and the received data, while x' is > the nearest correct code. > > mvh., > > David Does that work? While adjacent binary codes are always represented by single bit differences in gray, the converse is not true; single bit changes in gray are not necessarily adjacent codes in binary. Also, n-count changes in binary code are not necessarily represented by n-bit changes in gray. AndyArticle: 124061
> In general, I would say no. If the design is in structural > verilog (or the VHDL equivalent), directly instantiating gate > level primitives then it might be possible. (Synthesis from > behavioral verilog is likely not unique.) Well, what if to switch to lower level, some RTL? If so, there're will be any existing tool to answer my question?Article: 124062
Hi all, I'm implementing a PCI interface in FPGA, but I'm stuck trying to figuring out what happens with byte enables in burst read cycles. Specifications are not clear about this point, saying that if you perform a burst read, byte enable are *usually* all active on all cycles. Even figures always show this situation. This hide the real timing or behaviour of BEs. I mean: are in general BEs referred to the data present on the bus in next clock cycle? (BEs signals are asserted one clock in advance during read cycles...). Or this happens only on the first data cycle? To be more clear, I'll try to draw what I mean... :-) This is what specs show for a burst read cycle: AD <addr>-----<=0=><=1=><=2=>... BE <cmd=><=be0==============>... But if BE need to change during data phase will we have something like this: AD <addr>-----<=0=><=1=><=2=>... BE <cmd=><be0><be1><be2><be3>... or this: AD <addr>-----<=0=><=1=><=2=>... BE < cmd><be0=====><be1><be2>... Can anybody enlighten me? :-) Thank you in advance for any answer, and excuse me for this very specific question and for the cross post. AntonioArticle: 124063
Richard Melikson wrote: > I didn't mean it as a big question. It's quite simple, really - when > was the last time *you* Jonathan (and other readers interested in > sharing) used Gray codes in digital design, either in coding logic or > software ? Jonathan Kirwan wrote: > 2005, for an EEPROM counter. > Richard wrote: > An internal address counter for access to the EEPROM ? Why did you > choose Gray encoding in this case ? Suppose for the sake of argument that you have an EEPROM composed of individually writeable bits, and each bit has a limited endurance of 10,000 writes. If you want to store a 20-bit count in the EEPROM (e.g., a page counter for a laser printer, an odometer for a car, etc.), almost every increment will have to write multiple bits, and the least significant bit will be rewritten at every increment, so your EEPROM will wear out after 10,000 increments. By using gray code instead, every increment will affect exactly one bit, and the EEPROM will last for 200,000 increments. That's oversimilified because EEPROM erase (and thus the write endurance) is usually at the byte level, rather than the bit level. You could either store one bit per EEPROM byte, to get the behavior I described above, or adopt a scheme in which you increment entire bytes, but choose which byte to increment in a grey code addressing sequence. If the EEPROM bytes start as 0x00, and individual bits can be changed from zero to ones without having to erase the byte first, instead of incrementing the EEPROM byte you would use a progression like 00->01->03->07->0f etc., so you get eight "increments" of a byte value with no erase, and in doing so only use up one unit of write endurance for that byte. I independently devised such schemes for a product developed in 1987, but I'm sure that many other people have done similar things before and since. It wouldn't surprise me if some have been patented. EricArticle: 124064
Eric Smith wrote: > Richard Melikson wrote: > > I didn't mean it as a big question. It's quite simple, really - when > > was the last time *you* Jonathan (and other readers interested in > > sharing) used Gray codes in digital design, either in coding logic or > > software ? > > Jonathan Kirwan wrote: > > 2005, for an EEPROM counter. > > > Richard wrote: > > An internal address counter for access to the EEPROM ? Why did you > > choose Gray encoding in this case ? > > Suppose for the sake of argument that you have an EEPROM composed of > individually writeable bits, and each bit has a limited endurance of > 10,000 writes. If you want to store a 20-bit count in the EEPROM (e.g., a > page counter for a laser printer, an odometer for a car, etc.), almost every > increment will have to write multiple bits, and the least significant bit > will be rewritten at every increment, so your EEPROM will wear out after > 10,000 increments. By using gray code instead, every increment will affect > exactly one bit, and the EEPROM will last for 200,000 increments. > > That's oversimilified because EEPROM erase (and thus the write endurance) > is usually at the byte level, rather than the bit level. You could > either store one bit per EEPROM byte, to get the behavior I described above, > or adopt a scheme in which you increment entire bytes, but choose which > byte to increment in a grey code addressing sequence. > > If the EEPROM bytes start as 0x00, and individual bits can be changed from > zero to ones without having to erase the byte first, instead of incrementing > the EEPROM byte you would use a progression like 00->01->03->07->0f etc., > so you get eight "increments" of a byte value with no erase, and in doing so > only use up one unit of write endurance for that byte. > > I independently devised such schemes for a product developed in 1987, > but I'm sure that many other people have done similar things before and > since. It wouldn't surprise me if some have been patented. > > Eric don't use binary coding but unary coding. We use unary coding when we discuss TM. 0->no 1 1->one 1 2->two 1s 3->three 1s ... 10000->10 thousand 1s I remember there is a Chinese joke telling the story of unary coding.Article: 124065
<drop669@gmail.com> wrote in message news:1189533963.393524.214000@19g2000hsx.googlegroups.com... >> In general, I would say no. If the design is in structural >> verilog (or the VHDL equivalent), directly instantiating gate >> level primitives then it might be possible. (Synthesis from >> behavioral verilog is likely not unique.) > > Well, what if to switch to lower level, some RTL? If so, there're will > be any existing tool to answer my question? No tool beyond your own knowledge. By instantiating gate level primitives, you have the chance to know through your design how many LUTs you're affecting with any one input signal change. There is no tool that will summarize the number of gates changed by the change of an input. There is no tool that will provide the per-bit level of power usage. Again: why is this important to you? You have the task of building one table. The assumption we can make is that it doesn't have to be powered by a hand crank or button-cell batteries. There are no tools that will provide you with the microscopic scale of power consumption you desire.Article: 124066
It seems I have misplaced my VHDL book a long time ago and I can't figure out where I left it. In short: I need a new VHDL book :-( Can anyone recommend a good generic VHDL reference? I'm not looking for a book with a particular bias towards fpga design, asic design, or simulation. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 124067
"A.D." <isd_mod@libero.ix> wrote in message news:q3BFi.111012$U01.922629@twister1.libero.it... > Hi all, > I'm implementing a PCI interface in FPGA, but I'm stuck > trying to figuring out what happens with byte enables in > burst read cycles. Specifications are not clear about this > point, saying that if you perform a burst read, byte > enable are *usually* all active on all cycles. Even figures > always show this situation. This hide the real timing or > behaviour of BEs. I mean: are in general BEs referred > to the data present on the bus in next clock cycle? (BEs > signals are asserted one clock in advance during read > cycles...). Or this happens only on the first data cycle? > > To be more clear, I'll try to draw what I mean... :-) > > This is what specs show for a burst read cycle: > > AD <addr>-----<=0=><=1=><=2=>... > BE <cmd=><=be0==============>... > > But if BE need to change during data phase > will we have something like this: > > AD <addr>-----<=0=><=1=><=2=>... > BE <cmd=><be0><be1><be2><be3>... > > or this: > > AD <addr>-----<=0=><=1=><=2=>... > BE < cmd><be0=====><be1><be2>... > > > Can anybody enlighten me? :-) > Thank you in advance for any answer, and excuse > me for this very specific question and for the > cross post. > > Antonio While PCI Express has detailed the use of byte enables for the start and end of burst transactions, the PCI bursts tend to be linear from the start word address. Read Multiple Line bursts are terminated when there's no more data to feed because of cache-line or other memory boundary restrictions. A Read Multiple Line does not request a precise number of words or bytes so byte enables don't make much sense. If you need to read from an odd read boundary, do the byte gating yourself and don't expect the PCI interface to deliver everything you think you need for the partial word that starts you off. Is your need above and beyond typical use?Article: 124068
How do you get messages from comp.arch.fpga archives? Google brings up headings that I may want to read, however, when I click on those headings I go to the archives that are listed by year and month. There isn't a clear way to find the message that I wanted to read. Brad Smallridge Ai VisionArticle: 124069
richard.melikson@gmail.com wrote:
> So why do all synthesis tools propose "gray code" as one of the
> encodings of state machines ?
I expect that the original author got it wrong
and others copied the idea. A state is normally
decoded synchronously and the the coding scheme
makes no functional difference.
-- Mike Treseler
Article: 124070
richard.melikson@gmail.com wrote:
> How is Gray better than regular binary when you
> need to decode the states ?
Only if the decoding has to be asynchronous.
Note that it can take extra state bits
to keep all the transitions gray so
even in the asynchronous case there
may be no area savings.
-- Mike Treseler
Article: 124071richard.melikson@gmail.com wrote: > >> Binary-coded counter sequences often change multiple bits on one >> count transition. That can (will) lead to decoding glitches, >> especially when counter values are compared for identity. > > What do you mean by "compared for identity" - do you mean equality > of two multi-bit registers ? > > Also, what kind of glitches are you referring to here ? Logic > hazards ? All the same beast. When multiple bits can change at once, the precise moment of reading is highly critical. When only one bit can change at a time, the maximum error resulting from the moment of reading is 1 unit. If that bit oscillates on/off then the result will oscillate by 1 unit, while for a binary code it probably oscillates by 2**n units. This is why rotary position decoders are always handled in Gray code, for example. The same is advisable for an a/d converter, avoiding generating non-existant large spikes. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> -- Posted via a free Usenet account from http://www.teranews.comArticle: 124072
Hello Taco, taco wrote: > hello all, > I'm trying to compile the microblaze-toolchain from source on a 64 bits > linux system, but got stuck. The source from the petalogix repository > doesn't compile. a first problem was solved with help of colleague: > a declaration error in 2 header files of binutils/gas (just wondering if > this is done on purpose by petalogix..). I can assure you the source tarball you found on the PetaLogix website is the same as was used to build the gcc at that time. It builds fine on a RHEL/CentOS 3 machine, such as the one I am using right now. Regards, JohnArticle: 124073
On Sep 11, 6:39 pm, richard.melik...@gmail.com wrote: > > This technique is useful if you access RAM/ROM linearly as a FIFO. Say > > for example a video frame buffer. Using gray code instead of straight > > low to high addressing allows you to stream the data into or out of > > memory without using a latch. > > Could you elaborate on this, please - how does it avoid a latch, and > where does the latch come from anyway in straight addressing ? > Normally, reading from and writing to memory requires a "clock signal". The clock signal is used to control a latch. The purpose of this latch is to allow you to sample data only when the signal is stable. In other words the latch is there to ignore data when the address changes. Why you ask? Because when you change the address, not all bits of the address arrive at the same time. There are many reasons for why bits arrive at different times -- some signals need to travel on longer paths, some paths have thicker wires, some gates have imperfections causing delays etc. Take for example reding two consecutive memory locations: 5 and 6. The change from 5 to 6 is: 00000101 00000110 But because of unequal arrival times of the electrical signals, in reality what actually happens may very well be: 00000101 00000111 <-- for a very, very short time 00000110 This is what's called a glitch. This would obviously generate errors on the output. So what we usually do is we use a latch to ignore glitches. The typical write operation is: 1. change address. 2. toggle write signal to write data. Gray code avoids glitches in a different way. It avoids glitches by ensuring that only a single bit changes when the address change. This allows us to do everything in a single clock cycle: (write signal is always set) 1. change address and write data.Article: 124074
davew wrote:
> if I want
> a 2720X18 memory (48960 bits), the wizard will construct one out of 9
> 4096X2 memories (82944 bits) which is 60% efficient.
>
> Does anyone have a strategy for getting more efficiency of usage out of
> these blocks?
Skip the wizards, write code, use synthesis.
Quartus synthesis can do 4096x18 in 73728 bits.
http://home.comcast.net/~mike_treseler/block_ram.pdf
http://home.comcast.net/~mike_treseler/block_ram.vhd
-- Mike Treseler
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