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
I just downloaded ARChitect from www.arccores.com. Has anyone worked with this product before, and if so, what was your experience with it? It seems very powerful at first glance. Any comments appreciated. Matt Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23901
Bill Blyth wrote: > > I haven't used Spartan but I assume its the same as Virtex SelectMap. An > abort is triggered when you change from a write to a read when the you > haven't completed all the writing you told the the device would occur. Same > when reading. > > You then have to resync and start again. > > Bill Yes, I understand that. What I am not clear on is the details of what will abort the write. For example they make it sound as if simply removing the write signal in between CCLK edges will cause an abort even if it is in the correct state on the rising edge of CCLK. Can I connect the WRITE- signal to the WR- of a microProcessor and use address decoding to generate CCLK and CS-? It is not specified how to "resync". What is a synchronization word? And finally, what are packets??? > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:396E1143.F8CB2AA9@yahoo.com... > > 100 mS seems to be correct if you are using the serial programming > > modes, but check out pages 17-20 in the SpartanII data sheet. The slave > > parallel mode is much faster at 50 MHz CCLK with no waiting and 8 bits > > being writen per CCLK edge! This will load your XC2S150 in as little as > > 2.5 mS if your configuration logic can keep up. > > > > The only question I have in using this mode is whether the CS and WRITE > > signals may be deasserted between CCLK edges. They make it clear that > > you can cause a programming abort by not doing this properly, I don't > > think they make it clear as to what the required procedure is. > > > > I copied this from the new, *unlocked* Spartan II datasheet! > > > > "For the present example, the user holds WRITE and CS > > Low throughout the sequence of write operations. Note that > > when CS is asserted on successive CCLKs, WRITE must > > remain either asserted or de-asserted. Otherwise an abort > > will be initiated, as in the next section." > > > > I assume that they are saying if you clock CCLK with CS asserted, you > > had better not do a READ as opposed to a WRITE??? Or are they saying > > that you have to keep CS and WRITE asserted at all times once you start > > to program the chip? > > > > I had this exact same confusion with the way a similar mode in the > > Lucent FPGAs was described. > > > > I am also not clear about the use of the term "packets" on pages 18-19. > > > > "When using the Slave Parallel Mode, write operations send > > packets of byte-wide configuration data into the FPGA." > > > > In the abort section, they say you have to resync after an abort using a > > "new synchronization word" before sending new packets. What does this > > mean? What are packets? I don't plan to abort configuration loading, but > > I would like to understand this. > > > > > > > > Gary Watson wrote: > > > > > > By my reckoning, a XC2S150 part from Xilinx has about a million bits of > > > configuration data, and the Xilinx serial proms support a 10 MHz bit > rate. > > > Does that mean that it takes about 100ms to have valid outputs after > power > > > up? That would be OK for my application, but if it took much more than > that > > > I could run into some problems... > > > > > > -- > > > > > > Gary Watson > > > gary@nexsan.sex (Change dot sex to dot com to reply!!!) > > > Nexsan Technologies Ltd. > > > Derby DE21 7BF ENGLAND > > > http://www.nexsan.com > > > > -- > > > > Rick Collins > > > > rick.collins@XYarius.com > > > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design > > > > Arius > > 4 King Ave > > Frederick, MD 21701-3110 > > 301-682-7772 Voice > > 301-682-7666 FAX > > > > Internet URL http://www.arius.com -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23902
My interpretation of the operation is that CS and WRITE are always sampled on the CCLK positive edge. I use a free running CCLK and qualify write data with CS as data is not always available at that rate. The device expects a mixture of commands and data in 32 bit words unlike previous devices which were simply bit serial. Some of these commands contain length counts and these are matched to the data you write or read. If you change from writing to reading before you have satisfied one of these counts you will cause an abort. There is a new answer in the data base which details the status output on the selectmap port when an abort occurs if you need to find out why the abort happened. http://support.xilinx.com/techdocs/8520.htm You need to send sync patterns because internally the FPGA is 32 bit but the port is only 8 bit. The sync word realigns the interface. Bill "rickman" <spamgoeshere4@yahoo.com> wrote in message news:396F24B9.B5217381@yahoo.com... > Bill Blyth wrote: > > > > I haven't used Spartan but I assume its the same as Virtex SelectMap. An > > abort is triggered when you change from a write to a read when the you > > haven't completed all the writing you told the the device would occur. Same > > when reading. > > > > You then have to resync and start again. > > > > Bill > > Yes, I understand that. What I am not clear on is the details of what > will abort the write. For example they make it sound as if simply > removing the write signal in between CCLK edges will cause an abort even > if it is in the correct state on the rising edge of CCLK. > > Can I connect the WRITE- signal to the WR- of a microProcessor and use > address decoding to generate CCLK and CS-? > > It is not specified how to "resync". What is a synchronization word? And > finally, what are packets??? > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:396E1143.F8CB2AA9@yahoo.com... > > > 100 mS seems to be correct if you are using the serial programming > > > modes, but check out pages 17-20 in the SpartanII data sheet. The slave > > > parallel mode is much faster at 50 MHz CCLK with no waiting and 8 bits > > > being writen per CCLK edge! This will load your XC2S150 in as little as > > > 2.5 mS if your configuration logic can keep up. > > > > > > The only question I have in using this mode is whether the CS and WRITE > > > signals may be deasserted between CCLK edges. They make it clear that > > > you can cause a programming abort by not doing this properly, I don't > > > think they make it clear as to what the required procedure is. > > > > > > I copied this from the new, *unlocked* Spartan II datasheet! > > > > > > "For the present example, the user holds WRITE and CS > > > Low throughout the sequence of write operations. Note that > > > when CS is asserted on successive CCLKs, WRITE must > > > remain either asserted or de-asserted. Otherwise an abort > > > will be initiated, as in the next section." > > > > > > I assume that they are saying if you clock CCLK with CS asserted, you > > > had better not do a READ as opposed to a WRITE??? Or are they saying > > > that you have to keep CS and WRITE asserted at all times once you start > > > to program the chip? > > > > > > I had this exact same confusion with the way a similar mode in the > > > Lucent FPGAs was described. > > > > > > I am also not clear about the use of the term "packets" on pages 18-19. > > > > > > "When using the Slave Parallel Mode, write operations send > > > packets of byte-wide configuration data into the FPGA." > > > > > > In the abort section, they say you have to resync after an abort using a > > > "new synchronization word" before sending new packets. What does this > > > mean? What are packets? I don't plan to abort configuration loading, but > > > I would like to understand this. > > > > > > > > > > > > Gary Watson wrote: > > > > > > > > By my reckoning, a XC2S150 part from Xilinx has about a million bits of > > > > configuration data, and the Xilinx serial proms support a 10 MHz bit > > rate. > > > > Does that mean that it takes about 100ms to have valid outputs after > > power > > > > up? That would be OK for my application, but if it took much more than > > that > > > > I could run into some problems... > > > > > > > > -- > > > > > > > > Gary Watson > > > > gary@nexsan.sex (Change dot sex to dot com to reply!!!) > > > > Nexsan Technologies Ltd. > > > > Derby DE21 7BF ENGLAND > > > > http://www.nexsan.com > > > > > > -- > > > > > > Rick Collins > > > > > > rick.collins@XYarius.com > > > > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design > > > > > > Arius > > > 4 King Ave > > > Frederick, MD 21701-3110 > > > 301-682-7772 Voice > > > 301-682-7666 FAX > > > > > > Internet URL http://www.arius.com > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 23903
Hello, In my VHDL design I'm implementing a multiplexer that uses 19 x 32-bits register busses (because of 19 x serial data-transfer inputs into the register which are part of the design) as input and one 32-bits channel as output. I wonder if the FLEX devices are any good to use since I need many I/O ports and alot of connectivity and I'm having problems with hold times and the serial input clock which needs to run at 20 MHz. I'm not sure if Maxplus & flex devices are a good choice for this implementation. The mapping Maxplus did seemed to become better if I split up the 32-bit registers into 4 times 8-bit but still got hold time problems. Can anyone recommend other ways to tackle my problem or do I need other devices / software (Xilinx?). Regards, JasperArticle: 23904
Hello, Jasper.
In my recent design I've found that LPM_MUX megafunction in MAX+ creates
superfluous LCELL's when parameter LPM_SIZE is not equal the power of 2.
You can easily check it up by searching "LCELL(GND)" in your .rpt file
(which is
nonsensical of course).
If my guess-work is right AHDL example for first multiplexer's stage with
much better
synthesis (fitting, timing) results is listed below.
For building bigger size multiplexer you can cascade this subdesign
appropriate time.
SUBDESIGN MUX41 (
data[3..0] : INPUT=GND;
sel[1..0] : INPUT;
result : OUTPUT;)
VARIABLE
D0, D1, D2, D3 : NODE;
BEGIN
D0=!sel[1] & !sel[0] & data[0];
D1=!sel[1] & sel[0] & data[1];
D2= sel[1] & !sel[0] & data[2];
D3= sel[1] & sel[0] & data[3];
IF !used(data3) & !used(data2) & !used(data1) & used(data0) GENERATE
result = D0; END GENERATE;
IF !used(data3) & !used(data2) & used(data1) & !used(data0) GENERATE
result = D1; END GENERATE;
IF !used(data3) & !used(data2) & used(data1) & used(data0) GENERATE
result = D1 # D0; END GENERATE;
IF !used(data3) & used(data2) & !used(data1) & !used(data0) GENERATE
result = D2; END GENERATE;
IF !used(data3) & used(data2) & !used(data1) & used(data0) GENERATE
result = D2 # D0; END GENERATE;
IF !used(data3) & used(data2) & used(data1) & !used(data0) GENERATE
result = D2 # D1; END GENERATE;
IF !used(data3) & used(data2) & used(data1) & used(data0) GENERATE
result = D2 # LCELL(D1 # D0); END GENERATE;
IF used(data3) & !used(data2) & !used(data1) & !used(data0) GENERATE
result = D3; END GENERATE;
IF used(data3) & !used(data2) & !used(data1) & used(data0) GENERATE
result = D3 # D0; END GENERATE;
IF used(data3) & !used(data2) & used(data1) & !used(data0) GENERATE
result = D3 # D1; END GENERATE;
IF used(data3) & !used(data2) & used(data1) & used(data0) GENERATE
result = D3 # LCELL(D1 # D0); END GENERATE;
IF used(data3) & used(data2) & !used(data1) & !used(data0) GENERATE
result = D3 # D2; END GENERATE;
IF used(data3) & used(data2) & !used(data1) & used(data0) GENERATE
result = D3 # LCELL(D2 # D0); END GENERATE;
IF used(data3) & used(data2) & used(data1) & !used(data0) GENERATE
result = D3 # LCELL(D2 # D1); END GENERATE;
IF used(data3) & used(data2) & used(data1) & used(data0) GENERATE
result = D3 # D2 # CASCADE(D1 # D0); END GENERATE;
END;
Valeri Serebrianski.
Jasper Hendriks <REMOVE_mijJasper.Hendriks@sci.kun.nl> сообщил в новостях
следующее:8knaj1$i8b$1@wnnews.sci.kun.nl...
> Hello,
>
> In my VHDL design I'm implementing a multiplexer that uses 19 x 32-bits
> register busses (because of 19 x serial data-transfer inputs into the
> register which are part of the design) as input and one 32-bits channel as
> output. I wonder if the FLEX devices are any good to use since I need many
> I/O ports and alot of connectivity and I'm having problems with hold times
> and the serial input clock which needs to run at 20 MHz.
> I'm not sure if Maxplus & flex devices are a good choice for this
> implementation.
> The mapping Maxplus did seemed to become better if I split up the 32-bit
> registers into 4 times 8-bit but still got hold time problems.
> Can anyone recommend other ways to tackle my problem or do I need other
> devices / software (Xilinx?).
>
> Regards,
>
> Jasper
>
>
Article: 23905I've looked into this option. Problems are: Cypress/IDT dual port RAMs are much larger memories than I need. Also more expensive (~$100) than FPGAs I mentioned (~$20). FPGA solution has lower component count and takes less board space. DP RAMs in FPGA are faster than Cypress/IDT parts. In article <8kma09$o6o$1@nnrp1.deja.com>, klaro@my-deja.com writes: >> > I think it would be easier to look after a Cypress or ITD DualPort RAM, > and keep this part extarnally. > -- > KLAROArticle: 23906
Hello, Jasper.
In my recent design I've found that LPM_MUX megafunction in MAX+ creates
superfluous LCELL's when parameter LPM_SIZE is not equal the power of 2.
You can easily check it up by searching "LCELL(GND)" in your .rpt file
(which is
nonsensical of course).
If my guess-work is right AHDL example for first multiplexer's stage with
much better
synthesis (fitting, timing) results is listed below.
For building bigger size multiplexer you can cascade this subdesign
appropriate time.
SUBDESIGN MUX41 (
data[3..0] : INPUT=GND;
sel[1..0] : INPUT;
result : OUTPUT;)
VARIABLE
D0, D1, D2, D3 : NODE;
BEGIN
D0=!sel[1] & !sel[0] & data[0];
D1=!sel[1] & sel[0] & data[1];
D2= sel[1] & !sel[0] & data[2];
D3= sel[1] & sel[0] & data[3];
IF !used(data3) & !used(data2) & !used(data1) & used(data0) GENERATE
result = D0; END GENERATE;
IF !used(data3) & !used(data2) & used(data1) & !used(data0) GENERATE
result = D1; END GENERATE;
IF !used(data3) & !used(data2) & used(data1) & used(data0) GENERATE
result = D1 # D0; END GENERATE;
IF !used(data3) & used(data2) & !used(data1) & !used(data0) GENERATE
result = D2; END GENERATE;
IF !used(data3) & used(data2) & !used(data1) & used(data0) GENERATE
result = D2 # D0; END GENERATE;
IF !used(data3) & used(data2) & used(data1) & !used(data0) GENERATE
result = D2 # D1; END GENERATE;
IF !used(data3) & used(data2) & used(data1) & used(data0) GENERATE
result = D2 # LCELL(D1 # D0); END GENERATE;
IF used(data3) & !used(data2) & !used(data1) & !used(data0) GENERATE
result = D3; END GENERATE;
IF used(data3) & !used(data2) & !used(data1) & used(data0) GENERATE
result = D3 # D0; END GENERATE;
IF used(data3) & !used(data2) & used(data1) & !used(data0) GENERATE
result = D3 # D1; END GENERATE;
IF used(data3) & !used(data2) & used(data1) & used(data0) GENERATE
result = D3 # LCELL(D1 # D0); END GENERATE;
IF used(data3) & used(data2) & !used(data1) & !used(data0) GENERATE
result = D3 # D2; END GENERATE;
IF used(data3) & used(data2) & !used(data1) & used(data0) GENERATE
result = D3 # LCELL(D2 # D0); END GENERATE;
IF used(data3) & used(data2) & used(data1) & !used(data0) GENERATE
result = D3 # LCELL(D2 # D1); END GENERATE;
IF used(data3) & used(data2) & used(data1) & used(data0) GENERATE
result = D3 # D2 # CASCADE(D1 # D0); END GENERATE;
END;
Valeri Serebrianski.
> Hello,
>
> In my VHDL design I'm implementing a multiplexer that uses 19 x 32-bits
> register busses (because of 19 x serial data-transfer inputs into the
> register which are part of the design) as input and one 32-bits channel as
> output. I wonder if the FLEX devices are any good to use since I need many
> I/O ports and alot of connectivity and I'm having problems with hold times
> and the serial input clock which needs to run at 20 MHz.
> I'm not sure if Maxplus & flex devices are a good choice for this
> implementation.
> The mapping Maxplus did seemed to become better if I split up the 32-bit
> registers into 4 times 8-bit but still got hold time problems.
> Can anyone recommend other ways to tackle my problem or do I need other
> devices / software (Xilinx?).
>
> Regards,
>
> Jasper
>
>
Article: 23907
Hello, Jasper.
In my recent design I've found that LPM_MUX megafunction in MAX+ creates
superfluous LCELL's when parameter LPM_SIZE is not equal the power of 2.
You can easily check it up by searching "LCELL(GND)" in your .rpt file
(which is nonsensical of course).
If my guess-work is right AHDL example for first multiplexer's stage with
much better synthesis (fitting, timing) results is listed below.
For building bigger size multiplexer you can cascade this subdesign
appropriate time.
SUBDESIGN MUX41 (
data[3..0] : INPUT=GND;
sel[1..0] : INPUT;
result : OUTPUT;)
VARIABLE
D0, D1, D2, D3 : NODE;
BEGIN
D0=!sel[1] & !sel[0] & data[0];
D1=!sel[1] & sel[0] & data[1];
D2= sel[1] & !sel[0] & data[2];
D3= sel[1] & sel[0] & data[3];
IF !used(data3) & !used(data2) & !used(data1) & used(data0) GENERATE
result = D0; END GENERATE;
IF !used(data3) & !used(data2) & used(data1) & !used(data0) GENERATE
result = D1; END GENERATE;
IF !used(data3) & !used(data2) & used(data1) & used(data0) GENERATE
result = D1 # D0; END GENERATE;
IF !used(data3) & used(data2) & !used(data1) & !used(data0) GENERATE
result = D2; END GENERATE;
IF !used(data3) & used(data2) & !used(data1) & used(data0) GENERATE
result = D2 # D0; END GENERATE;
IF !used(data3) & used(data2) & used(data1) & !used(data0) GENERATE
result = D2 # D1; END GENERATE;
IF !used(data3) & used(data2) & used(data1) & used(data0) GENERATE
result = D2 # LCELL(D1 # D0); END GENERATE;
IF used(data3) & !used(data2) & !used(data1) & !used(data0) GENERATE
result = D3; END GENERATE;
IF used(data3) & !used(data2) & !used(data1) & used(data0) GENERATE
result = D3 # D0; END GENERATE;
IF used(data3) & !used(data2) & used(data1) & !used(data0) GENERATE
result = D3 # D1; END GENERATE;
IF used(data3) & !used(data2) & used(data1) & used(data0) GENERATE
result = D3 # LCELL(D1 # D0); END GENERATE;
IF used(data3) & used(data2) & !used(data1) & !used(data0) GENERATE
result = D3 # D2; END GENERATE;
IF used(data3) & used(data2) & !used(data1) & used(data0) GENERATE
result = D3 # LCELL(D2 # D0); END GENERATE;
IF used(data3) & used(data2) & used(data1) & !used(data0) GENERATE
result = D3 # LCELL(D2 # D1); END GENERATE;
IF used(data3) & used(data2) & used(data1) & used(data0) GENERATE
result = D3 # D2 # CASCADE(D1 # D0); END GENERATE;
END;
Valeri Serebrianski.
> Hello,
>
> In my VHDL design I'm implementing a multiplexer that uses 19 x 32-bits
> register busses (because of 19 x serial data-transfer inputs into the
> register which are part of the design) as input and one 32-bits channel as
> output. I wonder if the FLEX devices are any good to use since I need many
> I/O ports and alot of connectivity and I'm having problems with hold times
> and the serial input clock which needs to run at 20 MHz.
> I'm not sure if Maxplus & flex devices are a good choice for this
> implementation.
> The mapping Maxplus did seemed to become better if I split up the 32-bit
> registers into 4 times 8-bit but still got hold time problems.
> Can anyone recommend other ways to tackle my problem or do I need other
> devices / software (Xilinx?).
>
> Regards,
>
> Jasper
>
>
Article: 23908Actually, the way you describe what you are doing, you don't need dual ported RAM. Dual port memory is a little easier to use since it provides two address busses and separate conrols, but a single port RAM would work just as well if you don't need to use both ports at the same time. But with the amount of storage you need, this will require the use of the Block RAM in the Spartan II chips (I don't know much about the Altera). It sounds like your design is a pretty straight forward one and will fit on an XC2S30. These chips are not in production yet but are sampling. So I don't know that you will hear much about problems with them. Not that I expect any. Paul Smith wrote: > > Greetings, > > I'm looking at FPGAs with Dual Port RAM for an instrumentation project. I > want to continuosly record data from a Flash ADC and later read a subset of > that data aftera trigger arrives. I need about 2500 bytes or 20,000 bits of > dual port RAM, a write address counter, some small FIFOs, an adder to > calculate the read address, and a small amount of other logic. > > More information on my application is available at: > > http://dustbunny.physics.indiana.edu/~paul/hallDrd/ > > It looks like my best bets are the Altera ACEX series (EP1K30) or the Xilinx > Spartan II (XC2S30). > > I wonder if anyone out in usenet land has experience with either or both of > these parts? Any advice or warnings? Likes or dislikes about the Altera or > Xilinx tools? Compatibility with Mentor? Other considerations? Any other > devices I should consider? > > TIA! > > Paul Smith -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23909
Franz Hollerer wrote: > > hi, > > rickman wrote: > > > > Yes, I am with you. But this implies a lot of test vectors which should be > > > verified. > > > > Can you explain how you would verify the test vectors? How do you > > introduce your simulated faults and what type of faults do you simulate? > > To be honest, I have no concrete idea. I am a newcomer. I only have a > rough idea what I want do. So I started this discussion to see what > professionals > do. Boundary-scan is better suited to finding manufacturing defects than verifying components. However, getting a boundary-scan test to give you useful shorts and opens information on a complex board is mind numbing. I have not heard of any boundary-scan success stories. Anybody have one? The boundary-scan philosophy is based on the assumption that a significant percentage of the production run is destined to fail production tests forever without rework. Even if you believe this story, and enjoy the test development, things can go wrong. The tools can have bugs. The the component boundary scan description files can have errors. Simple changes can break the whole test. If the real objective is to built lots of boards that just work at first power-up, consider the possibility that your time might be better spent eliminating the process problems that result in solder shorts and opens. -- mike.treseler@flukenetworks.com or -- tres@tc.fluke.comArticle: 23910
No need to interpret. I found an explanation in the data sheet to Xapp176 which clearly explains the details of parallel configuration. It also shows how the data stream is different for the Spartan II, including configuration control commands. It would have been nice if they told you that the Spartan II chips use a very different configuation data format. This is only mentioned in an oblique reference under the heading "CCLK and LengthCount" in a section describing the BitGen Switches and Options in the app note. Further the app note is listed in the data sheet in the "Readback" section, and not in the configuration section. Bill Blyth wrote: > > My interpretation of the operation is that CS and WRITE are always sampled > on the CCLK positive edge. > > I use a free running CCLK and qualify write data with CS as data is not > always available at that rate. The device expects a mixture of commands and > data in 32 bit words unlike previous devices which were simply bit serial. > Some of these commands contain length counts and these are matched to the > data you write or read. If you change from writing to reading before you > have satisfied one of these counts you will cause an abort. > > There is a new answer in the data base which details the status output on > the selectmap port when an abort occurs if you need to find out why the > abort happened. > > http://support.xilinx.com/techdocs/8520.htm > > You need to send sync patterns because internally the FPGA is 32 bit but the > port is only 8 bit. The sync word realigns the interface. > > Bill > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:396F24B9.B5217381@yahoo.com... > > Bill Blyth wrote: > > > > > > I haven't used Spartan but I assume its the same as Virtex SelectMap. An > > > abort is triggered when you change from a write to a read when the you > > > haven't completed all the writing you told the the device would occur. > Same > > > when reading. > > > > > > You then have to resync and start again. > > > > > > Bill > > > > Yes, I understand that. What I am not clear on is the details of what > > will abort the write. For example they make it sound as if simply > > removing the write signal in between CCLK edges will cause an abort even > > if it is in the correct state on the rising edge of CCLK. > > > > Can I connect the WRITE- signal to the WR- of a microProcessor and use > > address decoding to generate CCLK and CS-? > > > > It is not specified how to "resync". What is a synchronization word? And > > finally, what are packets??? > > > > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > > news:396E1143.F8CB2AA9@yahoo.com... > > > > 100 mS seems to be correct if you are using the serial programming > > > > modes, but check out pages 17-20 in the SpartanII data sheet. The > slave > > > > parallel mode is much faster at 50 MHz CCLK with no waiting and 8 bits > > > > being writen per CCLK edge! This will load your XC2S150 in as little > as > > > > 2.5 mS if your configuration logic can keep up. > > > > > > > > The only question I have in using this mode is whether the CS and > WRITE > > > > signals may be deasserted between CCLK edges. They make it clear that > > > > you can cause a programming abort by not doing this properly, I don't > > > > think they make it clear as to what the required procedure is. > > > > > > > > I copied this from the new, *unlocked* Spartan II datasheet! > > > > > > > > "For the present example, the user holds WRITE and CS > > > > Low throughout the sequence of write operations. Note that > > > > when CS is asserted on successive CCLKs, WRITE must > > > > remain either asserted or de-asserted. Otherwise an abort > > > > will be initiated, as in the next section." > > > > > > > > I assume that they are saying if you clock CCLK with CS asserted, you > > > > had better not do a READ as opposed to a WRITE??? Or are they saying > > > > that you have to keep CS and WRITE asserted at all times once you > start > > > > to program the chip? > > > > > > > > I had this exact same confusion with the way a similar mode in the > > > > Lucent FPGAs was described. > > > > > > > > I am also not clear about the use of the term "packets" on pages > 18-19. > > > > > > > > "When using the Slave Parallel Mode, write operations send > > > > packets of byte-wide configuration data into the FPGA." > > > > > > > > In the abort section, they say you have to resync after an abort using > a > > > > "new synchronization word" before sending new packets. What does this > > > > mean? What are packets? I don't plan to abort configuration loading, > but > > > > I would like to understand this. > > > > > > > > > > > > > > > > Gary Watson wrote: > > > > > > > > > > By my reckoning, a XC2S150 part from Xilinx has about a million bits > of > > > > > configuration data, and the Xilinx serial proms support a 10 MHz bit > > > rate. > > > > > Does that mean that it takes about 100ms to have valid outputs after > > > power > > > > > up? That would be OK for my application, but if it took much more > than > > > that > > > > > I could run into some problems... > > > > > > > > > > -- > > > > > > > > > > Gary Watson > > > > > gary@nexsan.sex (Change dot sex to dot com to reply!!!) > > > > > Nexsan Technologies Ltd. > > > > > Derby DE21 7BF ENGLAND > > > > > http://www.nexsan.com > > > > > > > > -- > > > > > > > > Rick Collins > > > > > > > > rick.collins@XYarius.com > > > > > > > > Ignore the reply address. To email me use the above address with the > XY > > > > removed. > > > > > > > > > > > > > > > > Arius - A Signal Processing Solutions Company > > > > Specializing in DSP and FPGA design > > > > > > > > Arius > > > > 4 King Ave > > > > Frederick, MD 21701-3110 > > > > 301-682-7772 Voice > > > > 301-682-7666 FAX > > > > > > > > Internet URL http://www.arius.com > > > > -- > > > > Rick Collins > > > > rick.collins@XYarius.com > > > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design > > > > Arius > > 4 King Ave > > Frederick, MD 21701-3110 > > 301-682-7772 Voice > > 301-682-7666 FAX > > > > Internet URL http://www.arius.com -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23911
Mike Treseler wrote: > The boundary-scan philosophy is based on the assumption > that a significant percentage of the production run is > destined to fail production tests forever without rework. I have no idea what this means. Can you explain? > Even if you believe this story, and enjoy the test development, > things can go wrong. The tools can have bugs. > The the component boundary scan description files > can have errors. Simple changes can break the whole test. Of course you can have problems, but the idea is that you solve the problems in the test program once and then it is a useful test tool. > If the real objective is to built lots of boards that > just work at first power-up, consider the possibility > that your time might be better spent eliminating > the process problems that result in solder shorts > and opens. My objective is to find an inexpensive way to test the boards. Even if your failure rate is only 1 in 1,000, you have to test to find that one! I think I am missing your entire point. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23912
In article <396F57E2.D8B9D898@yahoo.com>, rickman <spamgoeshere4@yahoo.com> writes: > Actually, the way you describe what you are doing, you don't need dual > ported RAM. Dual port memory is a little easier to use since it provides > two address busses and separate conrols, but a single port RAM would > work just as well if you don't need to use both ports at the same time. > This wasn't clear from my description, but I do need two ports. With only one port, I would have to stop writing FADC data while reading out the RAM. This would have the system "dead" during the readout time. With two ports, the FADC data continues to be written while older data is read from the other port. Thus, no "deadtime". It's also not clear from my description, but only a small fraction of the data is "interesting". The "trigger" occurs about every 10 microseconds (on average). About 100 nS of FADC information is read out for each trigger. So 99% of the information in the RAM never gets read. Which 1% to read isn't known until about 2 microseconds after it gets written. PaulArticle: 23913
Your post is very intriguing. You state that your design runs at 60 MHz, but you also ask what timing analysis is. If you didn't do a timing analysis, how do you know how fast your design will run? Did you measure it in a circuit? If so, this is not a good way to check it out. Timing delays are dependant on temperature, power supply voltage and even the particular chip used. If any of this changes, your top speed may go down. Timing analysis is just software that looks at your design and calculates the worst case delays in the various components. It then looks at the way they are connected and calculates the delay for paths that begin and end at IO pins and FFs (or other clocked components). This will give you max delays in four classes; pin to pin, pin to FF, FF to FF, and FF to pin. Each of these delay classes must be considered separately. You tell the routing software how to control these delays with your timespecs. Further when you use these timespecs, the software will tell you how well they are met. In particular it will tell you a max clock speed for the FF to FF delays. But you still need to meet the delays requirements in the other three classes to work at that higher clock speed. Sreedhar Sampath wrote: > > hi, > I have a designed bus mastering for our board which runs at a speed > of 60Mhz. > > Now I have no idea of how to increase my speed. I would like to know what > does timing analysis mean in a design and how could we increase it. > > I have some idea on timespec when you define a particular delay between > two signals to be some value and the mapping algorithm tries to place it > in sych way that I get this timing. > > Is there any other way that I could increase my speed. > > Thanks > Sreedhar -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23914
Hi Don, I just returned from a meeting with some people who live in the valley and hearing that a one-bedroom flat can cost around $2000 a month rent! Add that to the fact that it's a crappy commute every day and I wonder what the attractions are! It seems that unless you've been through a fair few IPO's and gotten REALLY rich, you wont be able to buy a wardrobe, let alone a house to go with it and the family you might take with you. I did a search in Sunnyvale through go.com for a 3 bedroom house with a garage. Nothing special, but certainly a minimum for the average family with a couple of kids etc. Cheapest was about $400,000 with the tenth cheapest rising to almost $600K. Property number 25 was a cool $835,000 (Ok it had 4 bedrooms, and was 2000 sq.ft. but come on?) Maybe I picked a bad time, or keyed in some wrong search stuff, but this basically confirms what I thought: If a job is based in the valley it probably doesn't pay enough. You will work like a lunatic 18 hrs a day, sleep most nights in your "cube", live on pizza, spend hours counting the number of days to the scheduled IPO date (which will be delayed) and spend the rest of your time commuting and trying to remember what your wife/kids/girlfriend/cat look like. At the end of it (2 to 4 years?) you might get lucky and get a share of "the good stuff" in a brilliant IPO. By that time though you will be so knackered, you'll need to take a year off to recover. Then you'll have spent all your money and have to do the same thing all over again. The only advantages of the valley seem to be: 1 - If you get bored or hacked off, or don't think the company IPO will be anything special, you can pick up the phone and find work across the street in a few minutes (OK, maybe a day or two in reality) 2 - You might get really rich, However that seems to be less likely in the current climate where the fashion is returning for investing in companies that make products, actually own a unique technology and (shock horror) make a profit. I think it is probably fair to say that you could not persuade me to work in the Bay Area etc. It would be too much of a lifestyle downgrade! Of course if anyone wants to offer me an obscene amount of money to reconsider, my emails on the post :-) Cheers Stuart On Thu, 13 Jul 2000 00:04:00 GMT, husby@fnal.gov (Don Husby) wrote: >This is way off topic. > >I'm thinking it's time to leave my cushy science job in Chicago >and move to the West Coast. The scariest aspect of this is the >nightmare stories I've heard about the difficulties of finding >a place to live in Silicon Valley and the Bay area. > Is it really that bad? > Are there areas that are better/worse than others? > Will I be spending hours per day in my car trying to get to work? > > > >-- >Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby >Fermi National Accelerator Lab Phone: 630-840-3668 >Batavia, IL 60510 Fax: 630-840-5406 For Email remove "NOSPAM" from the addressArticle: 23915
rickman wrote: > > Mike Treseler wrote: > > The boundary-scan philosophy is based on the assumption > > that a significant percentage of the production run is > > destined to fail production tests forever without rework. > > I have no idea what this means. Can you explain? I was trying to politely say that boundary scan is a waste of time and that the goal should be using your final functional test as the board test. Ball Grid Array packages make this a realistic goal. > > Even if you believe this story, and enjoy the test development, > > things can go wrong. The tools can have bugs. > > The the component boundary scan description files > > can have errors. Simple changes can break the whole test. > > Of course you can have problems, but the idea is that you solve the > problems in the test program once and then it is a useful test tool. At Fluke we have concluded that the problems are insolvable. That's why I asked about success stories. If the manufacturer can't figure out why his own BSDL files are wrong, you are hosed. > > > If the real objective is to built lots of boards that > > just work at first power-up, consider the possibility > > that your time might be better spent eliminating > > the process problems that result in solder shorts > > and opens. > > My objective is to find an inexpensive way to test the boards. Even if > your failure rate is only 1 in 1,000, you have to test to find that one! When you get down to 1 in 1000, you can use manual methods to find the problem. I use BDM emulators to walk bits. -- mike.treseler@flukenetworks.com or -- tres@tc.fluke.comArticle: 23916
Paul Smith <paul@xanadu.physics.indiana.edu> schreef in berichtnieuws 8knpq8$ou5$1@flotsam.uits.indiana.edu... > In article <396F57E2.D8B9D898@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> writes: > > Actually, the way you describe what you are doing, you don't need dual > > ported RAM. Dual port memory is a little easier to use since it provides > > two address busses and separate conrols, but a single port RAM would > > work just as well if you don't need to use both ports at the same time. > > > > This wasn't clear from my description, but I do need two ports. With only > one port, I would have to stop writing FADC data while reading out the RAM. > This would have the system "dead" during the readout time. With two ports, > the FADC data continues to be written while older data is read from the other > port. Thus, no "deadtime". > > It's also not clear from my description, but only a small fraction of the data > is "interesting". The "trigger" occurs about every 10 microseconds (on > average). About 100 nS of FADC information is read out for each trigger. So > 99% of the information in the RAM never gets read. Which 1% to read isn't > known until about 2 microseconds after it gets written. The Flash ADC can write 1 sample to ram, and after that, the adressbus & data bus are switched over to the 'read' circuit' - which may or not may be triggered and actually interested in reading anything. After it has done one read, the FADC get the ram again, and can write another sample. And so forth. I don't know how many samples you have to take during this 100ns, but you need very fast ram. Also, because switching over the ram between each sample, doubles the accesfrequency for the ram. Or you could use 2 rams. The FADC writes to one ram continously, and after a trigger, the 2 rams are swapped. The FADC continous to write to the other ram now. In the mean time, the triggered part can read the other ram. -- Met vriendelijke groeten, Frank Bemelman (reageren per email ? verwijder dan de 'x' uit mijn emailadres)Article: 23917
you can always use two blocks of memory and while one side writes to one of the blocks, the other side reads the other block. When both sides are done, you switch the blocks. Of course this assumes consumer is faster than producer. As long as you have enough bandwidth, true multi-port access is almost never needed. (In fact I can't think of any case where true multi-port access would be needed, any ideas ?) paul@xanadu.physics.indiana.edu (Paul Smith) wrote: >In article <396F57E2.D8B9D898@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> writes: >> Actually, the way you describe what you are doing, you don't need dual >> ported RAM. Dual port memory is a little easier to use since it provides >> two address busses and separate conrols, but a single port RAM would >> work just as well if you don't need to use both ports at the same time. >> > >This wasn't clear from my description, but I do need two ports. With only >one port, I would have to stop writing FADC data while reading out the RAM. >This would have the system "dead" during the readout time. With two ports, >the FADC data continues to be written while older data is read from the other >port. Thus, no "deadtime". > >It's also not clear from my description, but only a small fraction of the data >is "interesting". The "trigger" occurs about every 10 microseconds (on >average). About 100 nS of FADC information is read out for each trigger. So >99% of the information in the RAM never gets read. Which 1% to read isn't >known until about 2 microseconds after it gets written. > > >Paul >Article: 23918
--------------BA82F179116C88BEFA18EAD1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Problem solved. It was a clock glitch, reflection, etc. Putting the scobe probe (8pF cap) on the clock line, solved the problem. (I had probed this clock previously, but after it went through some logic. Grr!). We subsequently changed a termination resistance on the clock line, from 50 ohm to 10 ohm. This solved the problem on the board (no probe needed). Apparently our board designer didn't do a very precise job of choosing the board resistance values (gross estimation, except for the address and data lines.) I have learned a lot about board-level debug this last week. Thanks for all your help. Matt Gavin Rockwell Collins > --------------BA82F179116C88BEFA18EAD1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <br>Problem solved. <p>It was a clock glitch, reflection, etc. Putting the scobe probe (8pF cap) <br>on the clock line, solved the problem. (I had probed this clock previously, <br>but after it went through some logic. Grr!). We subsequently changed <br>a termination resistance on the clock line, from 50 ohm to 10 ohm. <br>This solved the problem on the board (no probe needed). <br>Apparently our board designer didn't do a very precise job of <br>choosing the board resistance values (gross estimation, except <br>for the address and data lines.) <p>I have learned a lot about board-level debug this last week. <br>Thanks for all your help. <p>Matt Gavin <br>Rockwell Collins <blockquote TYPE=CITE><a href="http://www.arius.com"></a> </blockquote> </html> --------------BA82F179116C88BEFA18EAD1--Article: 23919
Mike Treseler wrote: > I was trying to politely say that boundary scan is > a waste of time and that the goal should be using > your final functional test as the board test. > Ball Grid Array packages make this a realistic goal. I understand the end result, but what is the reasoning? What is wrong with boundry scan? I have not tried boundry scan, but I think functional test is not as good at either checking for all the little problems that can creep into fabrication or for isolating a problem. I have some experience in manufacturing test where we wrote our own diagnostics for processor based designs (machines rather than just boards). This was very tedious and did not catch many bugs until they worked on it for a long time. On the other hand a walking ones and zeros test will catch many bugs and it should be fairly simple to write test patterns for non-JTAG parts as memory, UARTs... I guess I don't see how this is a bad way to test. Your earlier post seemed to be saying something about the way failures happen vs. what is being tested. I just didn't understand what you meant. I am currently using functional test on a small PC/104 DSP board. Because of the limited board space, we designed it such that a large portion of the board has to be working in order to allow the DSP to communicate. So if it doesn't come up, I have to get a scope out to find a short on the data bus. Boundry scan would find that at the same time it is testing. Since the DSP only needs 4 parts working to boot, I have thought about giving it boundry scan capabilities over the rest of the board. But the same problem still occurs, it can't communicate unless much of the board is working. I might add a small micro to the next board for this, but it would need to be more than the $2 part I was thinking of using. > At Fluke we have concluded that the problems are insolvable. > That's why I asked about success stories. > If the manufacturer can't figure out why his own > BSDL files are wrong, you are hosed. Wow! That is quite a statement! Can you give specific examples of wrong BSDL files? > > My objective is to find an inexpensive way to test the boards. Even if > > your failure rate is only 1 in 1,000, you have to test to find that one! > > When you get down to 1 in 1000, you can use manual methods > to find the problem. I use BDM emulators to walk bits. I am not talking about isolating the problem so that it can be fixed. Heck, I would be willing to throw out 1 in a 1000 boards. I am talking about figuring out which 1 of the 1000 boards is bad! You have to do some form of testing. It seems to me (at least for my boards) that boundry scan is about the simplest form of testing you can do. You are using the chips on the board to test the interconnects. Functional testing can be very difficult to design for high coverage. You can run a billion vectors through a data bus and you still won't find a problem with a chip select that is not being exercised. But I would like to hear about the problems you had in trying to use boundry scan test. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23920
It really doesn't matter since the Xilinx block RAMs are dual port. They have 4 K bits per block. So you will need 5 blocks which you can get in any but the smallest Spartan II parts (XC2S15). Paul Smith wrote: > > In article <396F57E2.D8B9D898@yahoo.com>, > rickman <spamgoeshere4@yahoo.com> writes: > > Actually, the way you describe what you are doing, you don't need dual > > ported RAM. Dual port memory is a little easier to use since it provides > > two address busses and separate conrols, but a single port RAM would > > work just as well if you don't need to use both ports at the same time. > > > > This wasn't clear from my description, but I do need two ports. With only > one port, I would have to stop writing FADC data while reading out the RAM. > This would have the system "dead" during the readout time. With two ports, > the FADC data continues to be written while older data is read from the other > port. Thus, no "deadtime". > > It's also not clear from my description, but only a small fraction of the data > is "interesting". The "trigger" occurs about every 10 microseconds (on > average). About 100 nS of FADC information is read out for each trigger. So > 99% of the information in the RAM never gets read. Which 1% to read isn't > known until about 2 microseconds after it gets written. > > Paul > -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23921
I've known several people who have moved to the Valley from out of state thinking that the salary they were getting here was great compared to what they were making back home. Now, they have a house half the size of what they had back home and a mortgage twice as large. The commute varies from 15 to 75+ miles (30 minutes to 2 Hours). I'm a native of San Jose, I would never live any where else but on thing is clear if we had not bought our home over ten years ago, we could not afford to live here. If my house was on the market today I could not afford it. You really have to do your homework before making the move. Not just cost of living but general quality of life. If you have school age children, California schools are not the best. If you want a quite, peaceful, good place to raise a family, THIS IS NOT IT. There is a lot to do and see, the weather is great, maybe its a better place to visit that to live in. Don Husby wrote: > This is way off topic. > > I'm thinking it's time to leave my cushy science job in Chicago > and move to the West Coast. The scariest aspect of this is the > nightmare stories I've heard about the difficulties of finding > a place to live in Silicon Valley and the Bay area. > Is it really that bad? > Are there areas that are better/worse than others? > Will I be spending hours per day in my car trying to get to work? > > -- > Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby > Fermi National Accelerator Lab Phone: 630-840-3668 > Batavia, IL 60510 Fax: 630-840-5406 -- ***************************** Anna M. Acevedo Xilinx University Program 2100 Logic Drive San Jose, CA 95124 PH: (408) 879-5338 FAX: (408) 879-4780 Email: anna.acevedo@xilinx.com http://www.xilinx.com/programs/univ.htm *****************************Article: 23922
Hi, when I create new HDL code (File/New/Verilog Module), how can I update the symbol ports? The standard symbol has no ports. Is there a way to generate them automatically? Or are they to be generated manualy(add port) ? Regards -- Jens Popp Institut fuer Rechnerstrukturen Universitaet Siegen Hoelderlinstr.3 D-57068 Siegen Germany mailto:popp@rs.uni-siegen.deArticle: 23923
Franz Hollerer <hollerer@hephy.oeaw.ac.at> wrote in message news:396C3C9D.5D9C5D9C@hephy.oeaw.ac.at... > Hi, > > I have to automate board level tests with tools from JTAG technologies. > The documentation gives an overview. But I don't exactly know how to > start. I miss the "big idea". I was at a trade show recently and got handed a copy of a 70 page booklet called "Boundary Scan Tutorial", published by a company called Asset InterTech, Ltd. Their address is Systems House, Petersfield Business Park, Petersfield, Hants, GU32 3QA, which is in England. Their web site is http://www.assett-intertech.com so maybe if you contact them and act interested in their boundary scan testers they might send you a copy of this free booklet. It is stritcly a tutorial, so I'm not sure what equipment they are selling, exactly. I think JTAG is a good way to program your in-circuit parts and verify that the complex parts are soldered properly -- as is pointed out elsewhere in this thread, if your 64 bit processor hangs it's a gold-plated bitch to scope the lines one-by-one to find that an address line is shorted to a data line. The proper place for this test to happen is immediately after the soldering process, to shorten the feedback loop. Without a good go/nogo test at the board house which flags the exact location of the problem, the process cannot be brought back under control. Simply knowing that a board is bad does not tell the operator if the oven is too hot or too cold -- he needs to see the specific problem to make that call. I am doubtful that doing the "Intest" functions of JTAG, where you test the internal logic inside the chip, are worth the effort though I know somebody who is doing it on a board with 15 BGA components -- and he swears by this approach. -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 23924
You may want to consider the East coast instead. Massachusetts is booming, there are wall to wall startups and the big companies like Sun, Cisco, Lucent are all building huge facilities. The housing is expensive compared to anywhere except Silicon Valley, by Valley standards its cheap, you should be able to buy a decent house for $350, there are million dollar houses but at least they are 5000sq/feet and have a couple of acres of land, in Silicon Valley a million dollars gets you a phone booth. The commutes are reasonable, the Chinese food isn't as good as the Valley but the Italian food is better. Don Husby wrote: > > This is way off topic. > > I'm thinking it's time to leave my cushy science job in Chicago > and move to the West Coast. The scariest aspect of this is the > nightmare stories I've heard about the difficulties of finding > a place to live in Silicon Valley and the Bay area. > Is it really that bad? > Are there areas that are better/worse than others? > Will I be spending hours per day in my car trying to get to work? > > -- > Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby > Fermi National Accelerator Lab Phone: 630-840-3668 > Batavia, IL 60510 Fax: 630-840-5406
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