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
Alessandro, You might make sure that the TRST pins is not tied to ground (as shown in fig. 29), this holds the JTAG config. logic in reset in the FPGA, and you can not JTAG scan though the device, or program the EPC2s. Mike O. Alessandro Patalani wrote: > I have a problem with the configuration of a 4 Altera Flex 10K20 Board > being programmed by means of an EPC2 connected to a BitBlaster cable. > To build the board I have followed the scheme on the Altera Application > Note 116, pag. 55, fig 29, but this seems not to work. We tried to > program the EPC2 using Max+Plus II Programmer trasferring a .pof file > (built on the 4 .sof files) specifically targeted to EPC2TC32. We are > not able to observe any output signal from the EPC2. The error message > displayed by the Programmer is "Unrecognizable devide". We are using 5V > for the Vpp and Vcc, having tied both Vppsel and Vccsel pins to GND like > > the Application Note suggested. > Have anyone had the same problem? Can anyone help me to understand where > > is the problem? > > Thank you in advance. > > Alessandro > > -- > Posted from beta.dmz-eu.st.com [164.129.1.35] > via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 31726
--------------65DC0298D3B7C00B0C17C9A4 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit There are several solutions to this problem. First, let me apologize for the XC4000 situation, where the GSR is just plain too long, and special tricks must be used to keep state machines properly reset. With Virtex and Spartan-II, we have sped up the GSR distribution to a few ns, so there should be no problem at global clock rates up to 150 MHz ( somewhat chip-size dependent, smaller chips are even better). You can also use a global clock line to drive all critical Clock Enables inactive, but you have only 4 clock lines available, and you may not want to interconnect all CEs. Virtex-II is even better. It gives you far more global clocks that might be used to distribute CE, and here is a much better solution: Disable any global clock for a few clock ticks after the end of GSR. Each Virtex-II global clock buffer is actually a clock multiplexer or clock enable circuit. So just feed a delayed version of GSR into the Global Clock Enable input, and the global clock will only become active after all flip-flops are no longer being held (re)set. As we explained in the data sheet and in our seminars, this clock enable or clock multiplexer circuit is absolutely positively glitch-free. Peter Alfke, Xilinx Applications Austin Franklin wrote: > FLAME ON... > > And this is a HUGE beef I've had with Xilinx for nearly ten years! Why is > the global reset signal NOT hard routed using a LOW SKEW net? Come on, this > isn't rocket science guys! I characterized this back on the 4k series in > the early 90's. I actually found that the GSR in a 4010 had nearly 80ns > skew across the part! You've got lots of clocks routed with low skew nets, > why has this not been done with the global reset? > > And then Xilinx tells users to NOT use the global reset even in the current > series parts, but TO burn routing resources in the chip for a reset signal! > This causes other issues, simply because the routing resources that are > taken up by this reset signal can significantly effect performance of the > design. > > I have always been able to use the GSR and accommodate the shortcomings of > the bad GSR routing with careful logic design. If you did follow Xilinx > "advice" and provide your own reset signal, take a look using FPGA Editor at > how much routing resources it takes! My compile times went from forty five > minutes to TEN minutes by using the GSR instead of a routed reset signal. > > FLAME turned down...but still burning with a trigger finger.... --------------65DC0298D3B7C00B0C17C9A4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> There are several solutions to this problem. <p>First, let me apologize for the XC4000 situation, where the GSR is just plain too long, and special tricks must be used to keep state machines properly reset. <p>With Virtex and Spartan-II, we have sped up the GSR distribution to a few ns, so there should be no problem at global clock rates up to 150 MHz ( somewhat chip-size dependent, smaller chips are even better). You can also use a global clock line to drive all critical Clock Enables inactive, but you have only 4 clock lines available, and you may not want to interconnect all CEs. <p>Virtex-II is even better. It gives you far more global clocks that might be used to distribute CE, <h2> and here is a much better solution:</h2> <p><br>Disable any global clock for a few clock ticks after the end of GSR. <br>Each Virtex-II global clock buffer is actually a clock multiplexer or clock enable circuit. So just feed a delayed version of GSR into the Global Clock Enable input, and the global clock will only become active after all flip-flops are no longer being held (re)set. <br>As we explained in the data sheet and in our seminars, this clock enable or clock multiplexer circuit is absolutely positively glitch-free. <p>Peter Alfke, Xilinx Applications <br> <br> <br> <br> <p>Austin Franklin wrote: <blockquote TYPE=CITE>FLAME ON... <p>And this is a HUGE beef I've had with Xilinx for nearly ten years! Why is <br>the global reset signal NOT hard routed using a LOW SKEW net? Come on, this <br>isn't rocket science guys! I characterized this back on the 4k series in <br>the early 90's. I actually found that the GSR in a 4010 had nearly 80ns <br>skew across the part! You've got lots of clocks routed with low skew nets, <br>why has this not been done with the global reset? <p>And then Xilinx tells users to NOT use the global reset even in the current <br>series parts, but TO burn routing resources in the chip for a reset signal! <br>This causes other issues, simply because the routing resources that are <br>taken up by this reset signal can significantly effect performance of the <br>design. <p>I have always been able to use the GSR and accommodate the shortcomings of <br>the bad GSR routing with careful logic design. If you did follow Xilinx <br>"advice" and provide your own reset signal, take a look using FPGA Editor at <br>how much routing resources it takes! My compile times went from forty five <br>minutes to TEN minutes by using the GSR instead of a routed reset signal. <p>FLAME turned down...but still burning with a trigger finger....</blockquote> </html> --------------65DC0298D3B7C00B0C17C9A4--Article: 31727
Peter Alfke <peter.alfke@xilinx.com> wrote:
>CoolRunner is very much alive and well, as part of Xilinx.
C'mon, Peter. The 5032 was canned by Xilinx along with some others and
caused big problems for us.
This was a particular disappointment. I expected this kind of behaviour
from Philips but not from Xilinx.
Although Xilinx did have some workarounds, the simplest way out was to
change to an Atmel part (drop in replacement, power wasn't too much of
an issue).
Richard
------------Richard Dungan-------------
Radix Electronic Designs, Orpington, UK
richardATradixDASHdesignDOTcoDOTuk
Web page: www.radix-design.co.uk
---------------------------------------
Article: 31728"Domagoj" <domagojtake_this_out@rasip.fer.hr> wrote in message news:<9fdtfp$7os$1@bagan.srce.hr>... > Hi! > > Has anybody done any comparison of > Pentium 4 vs. AMD architectures for PAR and > simulation ? What about RIMM/DRAM/DDR ? > > thx > > Regards, > Domagoj Babic > domagoj(et)rasip.fer.hr I didn't do any comparaison but I know that actually the xilinx aliance software doesn't support P4 because of a Java incompatibilityArticle: 31729
Well, I did not want to sound too glib, so I followed this up, 30 minutes later, with a detailed explanation how we had communicated this to our customers. On October 19, 2000 we sent notification that we would accept orders for these parts until April 27, 2001. That's six months warning! Not as much as we wanted to give ( and do give for parts that we originated), but we were stuck, we could not get these parts from the original manufacturer. And completely redesigning them for a different process did not make any sense. Here is what I posted, 30 minutes after my brash statement that "CoolRunner is alive and well": Seven month ago, Xilinx sent a note to CoolRunner customers that certain older CoolRunner would be discintinued, since the original fab will no longer make the devices. Here is the URL of that note http://www.xilinx.com/partinfo/notify/pdn0007.htm All the newer members of the CoolRunner family are very much alive, and so is the orignal design team, still located in Albuquerque as happy Xilinx employees, working on the next generation CoolRunner. To paraphrase Mark Twain: The rumors of CoolRunner's death are highly exaggerated. If you need CPLDs, CoolRunner is the way to go! Peter Alfke Richard Dungan wrote: > Peter Alfke <peter.alfke@xilinx.com> wrote: > > >CoolRunner is very much alive and well, as part of Xilinx. > > C'mon, Peter. The 5032 was canned by Xilinx along with some others and > caused big problems for us. > > This was a particular disappointment. I expected this kind of behaviour > from Philips but not from Xilinx. > > Although Xilinx did have some workarounds, the simplest way out was to > change to an Atmel part (drop in replacement, power wasn't too much of > an issue). > > Richard > > ------------Richard Dungan------------- > Radix Electronic Designs, Orpington, UK > richardATradixDASHdesignDOTcoDOTuk > Web page: www.radix-design.co.uk > ---------------------------------------Article: 31730
Well, I did not want to sound too glib, so I followed this up, 30 minutes later, with a detailed explanation how we had communicated this to our customers. On October 19, 2000 we sent notification that we would accept orders for these parts until April 27, 2001. That's six months warning! Not as much as we wanted to give ( and do give for parts that we originated), but we were stuck, we could not get these parts from the original manufacturer. And completely redesigning them for a different process did not make any sense. Here is what I posted, 30 minutes after my brash statement that "CoolRunner is alive and well": Seven month ago, Xilinx sent a note to CoolRunner customers that certain older CoolRunner would be discintinued, since the original fab will no longer make the devices. Here is the URL of that note http://www.xilinx.com/partinfo/notify/pdn0007.htm All the newer members of the CoolRunner family are very much alive, and so is the orignal design team, still located in Albuquerque as happy Xilinx employees, working on the next generation CoolRunner. To paraphrase Mark Twain: The rumors of CoolRunner's death are highly exaggerated. If you need CPLDs, CoolRunner is the way to go! Peter Alfke Richard Dungan wrote: > Peter Alfke <peter.alfke@xilinx.com> wrote: > > >CoolRunner is very much alive and well, as part of Xilinx. > > C'mon, Peter. The 5032 was canned by Xilinx along with some others and > caused big problems for us. > > This was a particular disappointment. I expected this kind of behaviour > from Philips but not from Xilinx. > > Although Xilinx did have some workarounds, the simplest way out was to > change to an Atmel part (drop in replacement, power wasn't too much of > an issue). > > Richard > > ------------Richard Dungan------------- > Radix Electronic Designs, Orpington, UK > richardATradixDASHdesignDOTcoDOTuk > Web page: www.radix-design.co.uk > ---------------------------------------Article: 31731
Hi Frederic,
That's rather interesting.... Could you please
explain Java incompatibility of P4 in more detail ?
I don't understand why is it not possible to make
JVM for P4... there should be no problems....
:-o
regards,
Domagoj Babic
domagoj(et)rasip.fer.hr
"Frederic Antonin" <fr_a69@hotmail.com> wrote in message
news:427c9348.0106041100.1227fcbf@posting.google.com...
> "Domagoj" <domagojtake_this_out@rasip.fer.hr> wrote in message
news:<9fdtfp$7os$1@bagan.srce.hr>...
> > Hi!
> >
> > Has anybody done any comparison of
> > Pentium 4 vs. AMD architectures for PAR and
> > simulation ? What about RIMM/DRAM/DDR ?
> >
> > thx
> >
> > Regards,
> > Domagoj Babic
> > domagoj(et)rasip.fer.hr
>
>
> I didn't do any comparaison but I know that actually the xilinx
> aliance software doesn't support P4 because of a Java incompatibility
Article: 31732> <snip> > I didn't get the optimal answer (3 FF, 3 LUT, 300MHz) until I switched > to Synplify Pro to use "FSM Explorer". It tries different FSM encodings > to find the best one. It takes a while, too (about 4 seconds for this > tiny design). > Why didn't you just apply the `syn_preserve' attribute to the counter bits which would keep them as a binary coded register ? Or syn_encoding="sequential" Synth tools are no different from any others and only give their best results after spending time learning how to use them and, of course, learning to work around the inevitable bugs. I can remember the early schematic capture packages being an order of magnitude more nightmarish to deal with and work around than anything I've experienced using HDL synthesis. In my view its a real shame I can't easily design the PCB in Verilog as well as the FPGAs/CPLDs.Article: 31733
Hi, Maybe I'm misunderstanding, but you want to use 3 Logic Cells (4 input LUT + DFFE) to make a counter that counts in the following sequence: 4, 7, 2, 3, 0, 1, 6, 5 I usually do not post as most people here are Xilinx users and probably don't want to hear from the Altera peanut gallery, but if you specifically state that you want 3 bits in the vector by using STD_LOGIC, then you will achieve your goal. The code will look like this: library ieee; use ieee.std_logic_1164.all; entity mod8cnt is port ( clk : in std_logic; q : out std_logic_vector(2 downto 0) ); end mod8cnt; architecture logic of mod8cnt is signal cnt : std_logic_vector(2 downto 0); begin process (clk) begin if rising_edge(clk) then case cnt is when "100" => cnt <= "111"; when "111" => cnt <= "010"; when "010" => cnt <= "011"; when "011" => cnt <= "000"; when "000" => cnt <= "001"; when "001" => cnt <= "110"; when "110" => cnt <= "101"; when "101" => cnt <= "100"; end case; end if; end process; q <= cnt; end logic; This gives 3 LC in an APEX20KE device through Synplify. I do not have accesss to Xilinx tools, so I cannot comment on that. Let me know if this helps. Brian Sullivan FAE Specialist Eastern North America Altera CorporationArticle: 31734
I am trying to implement a floating point arithmetic adder subtractor based on IEEE-754 standard I am comparing the results from my code with the Softfloat library results I have problems with some operations such as 0x807FFFFC + 0x3A000001 the softfloat produces 0x3A000000 but my code produces 0x3A000001 This problem occurs whenever the difference between the exponents is too large Can anyone point me to the possible source of error? Note: I am using round to nearest zero rounding (chupping) Thanks in advance Jamil KhatibArticle: 31735
I think, for many embedded people, the i8080A/i8085A open core is still useful. You can add any required circuit into the core as you like. And it will fit into a EPF6016A or it uses only less than 1400 LE in ALTERA. And the speed meter of MAX+PLUS2 marks about 10MHz without any effort to make the circuit faster. I implement the core with Mc6800/MCS6502 type buses. Then many instructions will run with [instruction length]+1 clock cycle. Then the effective clock frequency will be much higher. I used external RAM/ROM that were dead stock in my lab., then the real clock is only 2MHz to meet the 150nS ROM/RAM specification. The 8086 ISA also very useful for larger project, but it will require bigger core. Also Z80 uses more and more gates to implement. If you need 16bit or more architecture I also have a pretty small processor SN/X which will fit into just a EPF10K10! You can add any instructions or any circuit you like. The lecture note that uses SN/X also avaliable but only in Japanese. http://shimizu-lab.et.u-tokai.ac.jp/pgm/snx/index.html Regards, Naohiko Shimizu Dept. Communication Engr./Univ. TOKAI 1117 Kitakaname Hiratsuka 259-12 Japan TEL.+81-463-58-1211(ext. 4084) FAX.+81-463-58-8320 http://shimizu-lab.et.u-tokai.ac.jp/Article: 31736
bsulliva@altera.com (Brian_Sullivan) writes: > I usually do not post as most people here are Xilinx users and > probably don't want to hear from the Altera peanut gallery, but if you <snip> Hi, Brian. I don't know about everyone else, but i for one would like to see a lot more here from Altera. You're right that most people are Xilinx users, but when a given problem comes up, it would be nice to see how it is dealt with given a different architecture. I'm sure that there are things that people are trying to do that don't fit the Xilinx parts perfectly. Hoping you find the opportunity to speak for Altera's peanut gallery more often, -KentArticle: 31737
Michael Dales <michael@dcs.gla.ac.uk> writes: > Cheers for the reply. The component declaration was a standard one, > found in Fndtn\vhdl\src\unisims\unisim_VCOMP.vhd in Foundation. > > The problem seems to be more to do with my lack of experience than > anything else. I eventually noticed that the unisim file tells > synopsis to ignore the generic map for some reason. Armed with this > info and a hunt around the Xilinx answer database seemed to suggest > that I manually include the following component declaration: > > component LUT4 > generic (INIT : bit_vector := X"0000"); > port ( > O : out STD_ULOGIC; > I0 : in STD_ULOGIC; > I1 : in STD_ULOGIC; > I2 : in STD_ULOGIC; > I3 : in STD_ULOGIC); > end component; > > This seems to have enabled me to compile the circuit, though I've not > had time to test it for functional correctness to see if indeed my > INIT parameter made it thru to the end result. I seem to remember somewhere that to specify the initial contents of a RAM or LUT, you need to use an attribute, that the synthesizer will not grab it from the generic. Sorry I forgot to mention this before. Take a look at Xilinx answer 10070, I think it's exactly what you're looking for. A quick question: Why do you want to instantiate the LUT4 instead of describing what you want, and lettig the synthesizer do the rest? -KentArticle: 31738
Hi Brian, Brian_Sullivan wrote: > This gives 3 LC in an APEX20KE device through Synplify. I do not have > accesss to Xilinx tools, so I cannot comment on that. Let me know if > this helps. This code also gives 3 LUTs and 3FF in a Virtex-E, using Synplify (what do you mean, you don't have the Xilinx tools :) BTW, there's an error in the VHDL. VHDL (the language) specifies that all all choices are covered in a case statement. You covered 8 out of the 729 possible cases. The addition of the line when others => null; fixes this, and doesn't change the functionality. Regards, Allan. P.S. A significant number of questions in this newsgroup involve Altera parts. Why the silence from Altera? Brian_Sullivan wrote: > > Hi, > > Maybe I'm misunderstanding, but you want to use 3 Logic Cells (4 input > LUT + DFFE) to make a counter that counts in the following sequence: > > 4, 7, 2, 3, 0, 1, 6, 5 > > I usually do not post as most people here are Xilinx users and > probably don't want to hear from the Altera peanut gallery, but if you > specifically state that you want 3 bits in the vector by using > STD_LOGIC, then you will achieve your goal. The code will look like > this: > > library ieee; > use ieee.std_logic_1164.all; > > entity mod8cnt is port ( > clk : in std_logic; > q : out std_logic_vector(2 downto 0) > ); > end mod8cnt; > > architecture logic of mod8cnt is > > signal cnt : std_logic_vector(2 downto 0); > > begin > > process (clk) begin > if rising_edge(clk) then > case cnt is > when "100" => cnt <= "111"; > when "111" => cnt <= "010"; > when "010" => cnt <= "011"; > when "011" => cnt <= "000"; > when "000" => cnt <= "001"; > when "001" => cnt <= "110"; > when "110" => cnt <= "101"; > when "101" => cnt <= "100"; > end case; > end if; > end process; > > q <= cnt; > > end logic; > > This gives 3 LC in an APEX20KE device through Synplify. I do not have > accesss to Xilinx tools, so I cannot comment on that. Let me know if > this helps. > > Brian Sullivan > FAE Specialist > Eastern North America > Altera CorporationArticle: 31739
Kent Orthner wrote:
>
> Michael Dales <michael@dcs.gla.ac.uk> writes:
> > Cheers for the reply. The component declaration was a standard one,
> > found in Fndtn\vhdl\src\unisims\unisim_VCOMP.vhd in Foundation.
> >
> > The problem seems to be more to do with my lack of experience than
> > anything else. I eventually noticed that the unisim file tells
> > synopsis to ignore the generic map for some reason. Armed with this
> > info and a hunt around the Xilinx answer database seemed to suggest
> > that I manually include the following component declaration:
> >
> > component LUT4
> > generic (INIT : bit_vector := X"0000");
> > port (
> > O : out STD_ULOGIC;
> > I0 : in STD_ULOGIC;
> > I1 : in STD_ULOGIC;
> > I2 : in STD_ULOGIC;
> > I3 : in STD_ULOGIC);
> > end component;
> >
> > This seems to have enabled me to compile the circuit, though I've not
> > had time to test it for functional correctness to see if indeed my
> > INIT parameter made it thru to the end result.
>
> I seem to remember somewhere that to specify the initial contents of a
> RAM or LUT, you need to use an attribute, that the synthesizer will
> not grab it from the generic. Sorry I forgot to mention this before.
>
> Take a look at Xilinx answer 10070, I think it's exactly what you're
> looking for.
>
> A quick question: Why do you want to instantiate the LUT4 instead of
> describing what you want, and lettig the synthesizer do the rest?
Hi,
I had this same problem initialising block rams.
You need to use the generic to get it to simulate correctly, and the
attributes to get it to synthesise correctly. Why two different ways?
I don't know. Perhaps the tool vendors might like to comment.
I found the "best" way to deal with this was to create a new entity
(called e.g. my_LUT4) which takes the INIT bit vector as a generic.
This entity instantiates a LUT4 with the generic set appropriately, but
it also applies an attribute with the equivalent value.
(You'll need a bit_vector to string function for the attribute value.)
This way the code produces the same results for both simulation and
synthesis.
Regards,
Allan.
Article: 31740Allan Herriman wrote: > ... > constant num_counts : integer := 8; > > type count_array is array (0 to num_counts - 1) of integer; > > constant next_count : count_array := ( > 1,6,3,0,7,4,5,2 > ); > > signal count : integer range 0 to num_counts - 1; attribute syn_encoding of count : signal is "sequential"; > begin > > counter : process (clock) > begin > if (rising_edge(clock)) then > count <= next_count(count); > end if; > end process counter; > ... > Suprisingly, Synplify decided that this was best implemented as a > one-hot, and used 6 flip flops and 3 LUTs. Usually, the best implementation of a statemachine in an FPGA is one-hot. The thing I don't understand is why 8 states translate into 6 FFs in a one-hot machine. Onehot machines take a FF per state. -- Phil HaysArticle: 31741
In general, I agree. Grey code address counters and a comparitor in one clock domain. One trick I like to do is use an extra address bit. If you have a 16 word fifo, use a 5 bit address counter. The xor of the msbs of the read and write addresses tells you the difference between full and empty. The msb address bit, is of course, ignored by the fifo... Now, if I know which clock is slower, I do it differently. I keep track of the number of words in the fifo on the faster side by pushing and popping, not by comparingaddresses. I can set high and low water marks on the fast side, and send almost full or almost empty back across to the other side. This way, I don't have to compare addresses or do any math to figure out the number of words in the fifo. The only thing crossing the async boundary is either (push, almost full) or (pop, almost empty). One signal in each direction. Bob "Austin Franklin" <austin@dar54kroom.com> wrote in message news:9f9r7v$eq2$1@slb1.atl.mindspring.net... > To start with, you probably want to use separate gray coded counters for > each address. Also, the flag generation math is gray coded math too. As > you figured, you probably want to be careful with the flags. I typically > check/set the flags for multiple cycles in one domain, and register them in > the domain I am using the flag in. > > One thing to remember, is some of the flags need to have the respective > counter enable signal in their equations...it'll become obvious as you build > it why. > > "Jamil Khatib" <khatib@ieee.org> wrote in message > news:3B16BA19.BDF5EA0D@ieee.org... > > Hi, > > I am trying to implement a FIFO buffer with two different clocks for > > read and write. I am going to use Dual port memory core but I do not > > know how to handle the flags and how to track number of bytes in the > > buffer. > > moreover how can I avoid metastability on the flags > > > > Regards > > Jamil Khatib > > > >Article: 31742
Peter Alfke wrote: > If you need CPLDs, CoolRunner is the way to go! This implies that other CPLDs, such as the XC9500 series, are not the way to go. Does this mean the CoolRunner series will eventually supplant the XC9500 series? -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 31743
I just implied that if I were looking for a CPLD, my first choice would be CoolRunner. There may be reasons to choose other Xilinx FPGAs, or, heaven forbid, CPLDs from Altera, Lattice, Atmel or Cypress. CoolRunner with its ultra-low power consumption would be my first choice, but other considerations, architecture, packages, price, availability, familiarity, etc may pull in a different direction. That's why we still need smart engineers to make the choice. Peter Alfke ============================================ Dave Vanden Bout wrote: > Peter Alfke wrote: > > > If you need CPLDs, CoolRunner is the way to go! > > This implies that other CPLDs, such as the XC9500 series, are not the way to go. > Does this mean the CoolRunner series will eventually supplant the XC9500 series? > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 31744
iglam wrote: > In general, I agree. Grey code address counters and a comparitor in > one clock domain. One trick I like to do is use an extra address bit. > If you have a 16 word fifo, use a 5 bit address counter. The xor of > the msbs of the read and write addresses tells you the difference > between full and empty. The msb address bit, is of course, ignored > by the fifo... Are you sure this works? It would be very nice and efficient, but I have severe doubts that this simple logic gives you the right answer after the circular addresses have been chased around a few times. There are other, simple and safe ways to distinguish Full from Empty, but your suggestion is intriguing. I just don't believe it works...( See, I try very hard to be polite) > > > Now, if I know which clock is slower, you usually do not know, at least not in the general case > I do it differently. > I keep track of the number of words in the fifo on the faster side by > pushing and popping, not by comparingaddresses. I can set high > and low water marks on the fast side, and send almost full or > almost empty back across to the other side. This way, I don't > have to compare addresses or do any math to figure out the number > of words in the fifo. The only thing crossing the async boundary is > either (push, almost full) or (pop, almost empty). One signal in > each direction. Did you think this through? Irrespective of the relative frequency, you have to cope with read and write clocks that have any (!) phase relationship, including being simultaneous. And you have to think about metastability. This is tricky stuff. I think I have a watertight design that uses Gray (that's the correct spelling) addresses, a direction detector, and two comparators for Full and Empty that are each synchronous with the required clock domain ( Full with write, Empty with read). I can e-mail the description to anybody interested. Peter Alfke ( designed the industry's first FIFO, the Fairchild 3341, in 1971. ) > > > Bob > > "Article: 31745
Hi, Allan Herriman wrote: > > Kent Orthner wrote: > > I seem to remember somewhere that to specify the initial contents of a > > RAM or LUT, you need to use an attribute, that the synthesizer will > > not grab it from the generic. Sorry I forgot to mention this before. > > <SNIP> > > You need to use the generic to get it to simulate correctly, and the > attributes to get it to synthesise correctly. Why two different ways? > I don't know. Perhaps the tool vendors might like to comment. > Xilinx AE did clarify this few weeks back in this NG. Search for "Subject" See this thread: -------- From: Brian Philofsky (brian.philofsky@xilinx.com) Subject: Re: Fine phase shift in Virtex2 Newsgroups: comp.arch.fpga Date: 2001-05-15 08:54:21 PST ---------- HTH, Srini -- Srinivasan Venkataramanan (Srini) ASIC Design Engineer, Chennai (Madras), IndiaArticle: 31746
I've tried for several days to install Service Pack 8 under Solaris
(2.8). The Java based Xilinx Software installer takes two days to
replace some files before it crashes with the following message:
3_3_08i_sol $java.lang.OutOfMemoryError
at java.lang.StringBuffer.<init>(Compiled Code)
at java.io.BufferedReader.readLine(Compiled Code)
at com.xilinx.install.FileTools.appendToFile(Compiled Code)
at com.xilinx.install.FileTools.copyFile(Compiled Code)
at com.xilinx.install.FileTools.copyFile(Compiled Code)
at com.xilinx.install.FileTools.replaceTree(Compiled Code)
at com.xilinx.install.FileTools.replaceTree(Compiled Code)
at com.xilinx.install.FileTools.replaceTree(Compiled Code)
at com.xilinx.install.FileTools.replaceTree(Compiled Code)
at com.xilinx.install.setup.installSpFiles(Compiled Code)
at com.xilinx.install.setup.servicepackTimer_ActionPerformed(Compiled Code)
at com.xilinx.install.setup$SymAction.actionPerformed(Compiled Code)
at symantec.itools.util.Timer.sourceActionEvent(Compiled Code)
at symantec.itools.util.Timer.run(Compiled Code)
at java.lang.Thread.run(Compiled Code)
The machine has only 384MB RAM, but I would think that was sufficient
to copy some files. I'm the only one using the machine at the time and
there are no other programs (other than typical Solaris daemons)
running.
Have anybody installed SP8 under Solaris yet?
I think the Java based installer is a big disaster. Why make a program
which takes days to copy some files when you can do it with a simple
cpio command?
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 31747Kent Orthner wrote: > bsulliva@altera.com (Brian_Sullivan) writes: > > I usually do not post as most people here are Xilinx users and > > probably don't want to hear from the Altera peanut gallery, but if you > > <snip> > > Hi, Brian. > > I don't know about everyone else, but i for one would like to see a lot > more here from Altera. You're right that most people are Xilinx users, > but when a given problem comes up, it would be nice to see how it is > dealt with given a different architecture. > > I'm sure that there are things that people are trying to do that don't > fit the Xilinx parts perfectly. > > Hoping you find the opportunity to speak for Altera's > peanut gallery more often, > -Kent I've, Xilinx bigot though I am, have often wondered about this. At least part of the answer was supplied somewhere in another thread by Peter Alfke (?) when he said that Altera employees are not allowed to post on this NG [Peter A. can you confirm this]. So us lucky Xilinx users can sometimes get answers direct from them that know. Its actually quite impressive how willing Xilinx employees are to stand and be shot at in this NG. An example of the fact, ignored by all marketing theory & practice, that being able to admit your failings & errors in a public forum can enhance your reputation rather than diminish it.Article: 31748
Hi Alfredo, "..Xilinx keeps the interpretation of the bitstream a closely guarded secret.." It's quotation from Xilinx "The Programmable Logic Data Book ". Best regards, Vlad. Alfredo Benso wrote: > > Hi everybody, > I am a researcher at Politecnico di Torino in Italy. > I am looking for information about the format of the Xilinx configuration > bit stream. Is the format public? Is there some document or file available > explaining how to generate a stream of configuration bits for a Xiling FPGA? > > Anybody can help? > > Thanks Alfredo > > ----ooo---ooo---ooo---ooo---- > BENSO Alfredo, PhD > > Politecnico di Torino > > Dip. Automatica e Informatica > > C.so Duca degli Abruzzi 24 > > Torino - Italy > > Phone: +39-011-564.7080 > > Fax: +39-011-564.7099 > > email: alfredo.benso@polito.it > > ----------ooo---ooo-------------Article: 31749
Why not get the Atmel FIGARO (or IDS 7.x as it is also called) tool for Free! It is present on the System Designer CD which is about to be shipped out any time now. Atmel has an advantage in the many small SRAM blocks which can be used for registers, even in small designs, but lack the H/W Carry for arithmetics. Bet you this time Ray :-) The largest size FPGAs currently available are the AT94K40 FPSLIC which has (in addition to the AVR part) 40 kgates and up to 12 kB of 8 bit SRAM useable by the FPGA -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel Sweden "Dave Feustel" <dfeustel@mindspring.com> skrev i meddelandet news:9fbi6n$29i$1@slb2.atl.mindspring.net... > I now have the Open Tech 1.1.0 CDROM set > Can any of the tools on this cdrom set generate > FPGA configuration bitstreamss for Atmel Parts? > (Particularly the Atmel FPSLIC) > > How about for Xilinx parts (Spartan-2, Virtex)? > > Which parts (Atmel, Xilinx, other) are best for > implementing open cores? > > Thanks, > > df > > > >
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