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
"Sean Durkin" <smd@despammed.com> wrote in message news:4hl7ujF56fsU1@individual.net... > > Well, I did the same thing in a Virtex-II Pro, and it seems to be the > same there (i.e. you're not supposed to use the differential termination > when VCCO=3.3V), even though it's not that explicitely stated in the > documentation. On that board it works perfectly, even though the > termination must be off there as well. Back then I did measurements with > a scope (at the balls) and didn't notice any obvious reflections or > weird behaviour because of impedance mismatch. On some IOs I had > external resistors and did comparisions between external and internal > termination, didn't make much of a difference. The only thing different > now is the FPGA. So, it might work there as well. > Hi Sean, I checked an old prototype design of my own, and I used the same thing as you for V2PRO. The problem was that I wanted to use the differential clock inputs on bank 4, but this was the same bank as my config pins which came from a 3.3V bus, so it had Vcco = 3.3V. All worked fine on the clock inputs. (Although maybe data inputs would have been a better test.) In the production version, I put a level translator on the bus and changed Vcco to 2.5V, but only for peace of mind. It always seemed to me rather odd that the receivers are powered from Vccaux, but the Rterm depends on Vcco. I wonder what's going on there? Cheers, Syms.Article: 105126
It's now been christened and had the obligatory bottle of Champers smashed. Darnaw1 is the name to look for. John Adair wrote: > Project now underway. I will post seperately when I have expected dates > for something being really available for sale. It is Spartan-3E based > this time. > > John Adair > Enterpoint Ltd. > > radarman wrote: > > John Adair wrote: > > > Following our recent Swinyard1 (Virtex-4) release we are now looking at the > > > Swinyard2 module concept which will be based on a middle end Virtex-5 > > > (initial XC5VLX50 and others) that will be supported by our Broaddown series > > > of main development boards. Bearing in mind this a small module what > > > features would you like us to put on this module? > > > > > > and what did you all think of the general Swinyard concept? > > > > > > This is you chance to influence what we deliver to the marketplace so do let > > > us know. > > > > > > John Adair > > > Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development > > > Board. > > > http://www.enterpoint.co.uk > > > > I would concur with some of the other posters. What would be really > > nice is a selection of decent size Spartan / Virtex parts on a PGA > > board that could be plugged into a socket 370 or socket 478 ZIF. These > > boards should have plenty of bypass caps on them - and it would be nice > > if these boards had a platform flash on them - making them, in essence, > > very nice CPLD's. If done properly, you could even strap a standard > > heatsink/fan unit on top! > > > > There are companies out there that have BGA -> PGA adapters, but then > > you have the little trick of getting the BGA on the board - a > > non-trivial task at best. I would definitely be interested in a > > pre-fitted, tested, PGA module with a Spartan 3/3E or Virtex II/II Pro > > BGA mounted on it. > > > > An ideal board would have: > > > > 1) Standard, commercially available socket pattern for the PGA. > > 2) Onboard 3.3 -> <core voltage> regulator > > 3) Bypass capacitors > > 4) Platform flash > > 5) Optional DDR SDRAM pads (or even devices). These could be on a > > "wing" that extends out past the socket like the Macintosh G3/G4 > > processor modules. > > 6) Reasonably high capacity XIlinx or Altera FPGA. > > > > Actually, if you could just make a G3/G4 processor module with a Virtex > > II Pro, you might be able to use an old Macintosh AS a development > > board!Article: 105127
The FSL is just a simple set of FIFOs . You would need some kind of state machine to read data out (and write to) these fifos. Yes, you could also have some logic generate an IRQ when the FIFO is Full, Etc. As far as data rate, The read and write FIFO is synschrounous to your microblaze clock. I think it is a single cycle instruction to to a non-blocking write to a FSL. Could take 2 or more but I can't remember. The rest of the speed is dependent our your state machine to grab data about of the FIFO and move it elsewhere. It would have been really nice for xilinx to put in an instruction (OR EVEN A FLAG) to tell me if there is data in the read fifo. OPB is slow 10-15 clks per transaction. It is useful though, and simple if you use the IPIF template. If you wish to do OPB master transactions from a peripheral on the bus, I would recommend just reading the OPB spec and making your own piece of IP. -Eli Christian Schleiffer wrote: > Hi everybody, > > at the moment, I'm facing the decision wether to connect to a MicroBlaze > through OPB or FSL. > The scenario is as following: I have a huge parallel computing device > with a 64 bit backplane (only moderate data throughput is required). > This backplane has to be interfaced to a MircoBlaze being the central > controller of the device. > Implementing an FSL interface seems a lot easier to me but I can't find > any comparisons of data rates, latency and so forth. Does anybody have > any suggestions on the topic? > Is it possible to trigger interrupts on arriving data with the FSL? > > Best regards > /Chris > > -- > Christian Schleiffer > Communication Security (COSY) > Dept. of Electr. Eng. & Information Science > Ruhr-University Bochum > http://www.crypto.rub.de > cschleiffer@crypto.rub.deArticle: 105128
Hello, usually a reset signal is applied to put the FFs of an FPGA into a known state. Just some days ago I had a discussion. Someone's point of view is, that a reset is not necessary, since the FF's output will be always zero, after applying the voltage. Does this happen in FPGAs really, especially in a Spartan3? Bye TomArticle: 105129
Hi Jonathan, It seems you are very familiar with Batcher algorithm. 1. I would like to know why you get 543 compare/swap blocks? It has (lg N)*((lg N)+1)/2 stages based on formula of Knuth Vol 3, p.113. For N= 64, it has 21 stages. With n/2 comparators at each stage, it means it has 32 comparators at each stage. 32*21 = 672 /= 543? 2. How did you get the conclusion: the longest path goes through 21 of these blocks. I think because it is pipelined, the longest path goes through only 1 block, why it is 21 blocks? Thank you. WengArticle: 105130
Thomas Reinemann wrote: > Hello, > > usually a reset signal is applied to put the FFs of an FPGA into a known > state. Just some days ago I had a discussion. Someone's point of view > is, that a reset is not necessary, since the FF's output will be always > zero, after applying the voltage. Does this happen in FPGAs really, > especially in a Spartan3? > > Bye Tom The state of I/Os on a Spartan3 is known immediately post-configuration (and may be high, low, Z or input - you can specify it in the constraints), but that is the only time it's known, without knowing implementation details. If you are, however, in an environment with lots of clocks and signals (pretty much the standard, one might think) you have to wait until the *system* is in a known state. The best way to do that is with a global reset. Then there's the time when a system controller needs to reset just the FPGA (quite common), so a local reset for that purpose is always a good idea [tm]. Just my $0.02 Cheers PeteSArticle: 105131
Thomas Reinemann wrote: > Hello, > > usually a reset signal is applied to put the FFs of an FPGA into a known > state. Just some days ago I had a discussion. Someone's point of view > is, that a reset is not necessary, since the FF's output will be always > zero, after applying the voltage. Does this happen in FPGAs really, > especially in a Spartan3? > > Bye Tom 1 - If it were guarenteed that logic would always come up in a known and valid state, why would the manufacturer include pins that are dedicated to being a global reset? Does most logic power up into a known and valid state or does it need a solid reset signal? 2 - What about a brown out condition that scrambles the logic. Does the device contain a built in power supply monitor that detects the brownout and asserts a proper reset? 3 - what about an application where a processor or other system needs to control the timing of the reset or wants to reset the circuit on watchdog timeout? 4 - Would you rather be safe or sorry?Article: 105132
HI, I have MIG 1.5 installed and want to test the K4T51083QC-ZCD5 Samsung DDR2 chips wich reside on our FPGA prototyping board. However it seems that MIG does not support any RAM chips beside Micron ones. Does anybody know if is possible to manipulte the output files to support the chip above? Are there plans from xilinx so support additional chips in the future? When? Any other options? I saw a DDR controller on opencores.org but no DDR2.Article: 105133
Thank you very much for helping me. Unfortunately I still can't do it. I cant create instantiation template with ISE because it does not give such option and xst won't accpet mine instantiation template (when I'm trying to implement the design it gives me an error saying that it couldn't "resolve" this component). Has anyone used this counter at all?Article: 105134
Noway2 wrote:
> Thomas Reinemann wrote:
> > Hello,
> >
> > usually a reset signal is applied to put the FFs of an FPGA into a known
> > state. Just some days ago I had a discussion. Someone's point of view
> > is, that a reset is not necessary, since the FF's output will be always
> > zero, after applying the voltage. Does this happen in FPGAs really,
> > especially in a Spartan3?
> >
> > Bye Tom
>
> 1 - If it were guarenteed that logic would always come up in a known
> and valid state, why would the manufacturer include pins that are
> dedicated to being a global reset? Does most logic power up into a
> known and valid state or does it need a solid reset signal?
> 2 - What about a brown out condition that scrambles the logic. Does
> the device contain a built in power supply monitor that detects the
> brownout and asserts a proper reset?
> 3 - what about an application where a processor or other system needs
> to control the timing of the reset or wants to reset the circuit on
> watchdog timeout?
> 4 - Would you rather be safe or sorry?
One more thing I forgot to mention.
Unless you specify it in the contraints file, any FSM controls (usually
one-hot encoded) will come up cleared, which is an invalid state for a
one-hot encoder. The reset is usually used (and should be) to get the
FSM back to the default (usually idle, but could be anything) state
Something like this:
//parameters for processor bus state machine
parameter statecount = 8;
parameter idle = { {(statecount-1){1'b0}},1'b1};
parameter int_write = idle<<1;
parameter int_read = int_write<<1;
parameter switch_write = int_read<<1;
parameter switch_write2 = switch_write<<1;
parameter switch_read = switch_write2<<1;
parameter switch_read2 = switch_read<<1;
parameter switch_end = switch_read2<<1;
//processor interface state machine
always @ (posedge clk or posedge rst) begin
if (rst) begin
switch_exception <= 1'b0;
cmcbus_wr <= 1'b0;
cmcbus_rd <= 1'b0;
cmcbus_rd_clr <= 1'b0;
addrdata <= 32'h00_00_00_00;
parity3 <= 1'b0;
parity2 <= 1'b0;
proc_parity_error <= 1'b0;
proc_ad_rdy <= 1'b0;
switch0_cs_l <= 1'b0;
switch1_cs_l <= 1'b0;
switch_rw <= 1'b0;
switch0_request <= 1'b0;
switch1_request <= 1'b0;
state <= idle;
end
// end of reset section
else begin
case (state)
idle: begin
addrdata <= proc_ad; //continuously load in new bus value
parity3 <= proc_parity3;
parity2 <= proc_parity2;
proc_parity_error <= 1'b0;
cmcbus_wr <= 1'b0;
cmcbus_rd <= 1'b0;
cmcbus_rd_clr <= 1'b0;
proc_ad_rdy <= proc_reset_out_l_use;
switch_rw <= proc_reset_out_l_use; //default to a read
switch0_request <= proc_reset_out_l_use;
switch1_request <= proc_reset_out_l_use;
switch0_cs_l <= proc_reset_out_l_use;
switch1_cs_l <= proc_reset_out_l_use;
if (cs7 & !proc_ad_we_l) begin //internal write
addrdata <= addrdata; //hold bus values
parity3 <= parity3;
// and so forth
Cheers
PeteS
Article: 105135Thomas Reinemann wrote: > Hello, > > usually a reset signal is applied to put the FFs of an FPGA into a known > state. Just some days ago I had a discussion. Someone's point of view > is, that a reset is not necessary, since the FF's output will be always > zero, after applying the voltage. Does this happen in FPGAs really, > especially in a Spartan3? > > Bye Tom a Spartan3 will "live-up" in a known state (after configuration), because FF's inital value is stored within the bitstream - this does NOT mean, that the FFs will start at '0': this depends on your hdl-code (and the tools).Article: 105136
"Thomas Reinemann" <thomas.reinemann@aucotronics.de> wrote in message news:e981ph$ur5$1@news.boerde.de... > Hello, > usually a reset signal is applied to put the FFs of an FPGA into a known > state. Just some days ago I had a discussion. Someone's point of view > is, that a reset is not necessary, since the FF's output will be always > zero, after applying the voltage. Does this happen in FPGAs really, > especially in a Spartan3? > Bye Tom If you use any form of PLL/DLL in your design I don't think you can be sure of what's going to happen until it's locked. This can throw logic/state machines into complete disarray. I generate a synchronous reset which de-activates some period after all my PLLs have locked. NialArticle: 105137
Hej, thanks for the answer. > The FSL is just a simple set of FIFOs . You would need some kind of > state machine to read data out (and write to) these fifos. Yes, you > could also have some logic generate an IRQ when the FIFO is Full, Etc. The hardware interface is no problem at all and my bus connection will have a system synchronous part as well. Maybe I even don't have to worry about IRQs: the controller will be running uCLinux and I just read about an official FSL driver doing the polling job. I have to get deeper into that uCLinux stuff first, I think. > As far as data rate, The read and write FIFO is synschrounous to your > microblaze clock. I think it is a single cycle instruction to to a > non-blocking write to a FSL. Could take 2 or more but I can't remember. Yes, non-blocking write and read operations take 2 instruction cycles. > The rest of the speed is dependent our your state machine to grab data > about of the FIFO and move it elsewhere. It would have been really nice > for xilinx to put in an instruction (OR EVEN A FLAG) to tell me if there > is data in the read fifo. > > OPB is slow 10-15 clks per transaction. It is useful though, and simple That's a little slow since I have additional latency in the attached bus interface and on the software side. Too bad, the memory mapped IO approach would have been quite nice... > if you use the IPIF template. If you wish to do OPB master transactions > from a peripheral on the bus, I would recommend just reading the OPB > spec and making your own piece of IP. > > -Eli Bye /Chris -- Christian Schleiffer Communication Security (COSY) Dept. of Electr. Eng. & Information Science Ruhr-University Bochum, Germany http://www.crypto.rub.de cschleiffer@crypto.rub.deArticle: 105138
heinerlitz@gmx.de wrote: > HI, > > I have MIG 1.5 installed and want to test the K4T51083QC-ZCD5 Samsung > DDR2 chips wich reside on our FPGA prototyping board. > However it seems that MIG does not support any RAM chips beside Micron > ones. > Does anybody know if is possible to manipulte the output files to > support the chip above? Are there plans from xilinx so support > additional chips in the future? When? > > Any other options? I saw a DDR controller on opencores.org but no DDR2. I don't have the Samsung datasheet, but there will be a Micron equivalent. Choose that chip when generating the MIG controller. There will be a parameter file generated as part of the design. You can fine tune any parameters there if needed. If you're targeting Virtex 4, MIG1.5 DDR2 uses the FIFO16. You'll want to fix the read/write address FIFO. I used CoreGen to make a blockram FIFO, but Xilinx has an app note on FIFO16 workarounds. I found that under certain conditions, the controller would have 'runaway' read cycles, where the controller thought that the FIFO still had addressess to read from so it would constantly read from the same location. --- Joe Samson Pixel VelocityArticle: 105139
Hi guys, I posted my problem a few days ago but I think I didn't make my points clear so I've decided to post it again. I have a very simple Microblaze based system which just has the processor and LMB BRAMs for instruction and data. I'm running my code on this system and I basically want to measure the power consumption of the system. I've generated a .vcd file by behavioral simulation of my design and estimated the power with that. But it seems that it is far unrealistic. As well by behavioral simulation I could verify my system behavior. I was monitoring my ilmb_lmb_abus which was the address bus of the instruction port of the microblaze and on the other hand I had the assembly code of my software so I could see what's going on in the system. However now to get a better estimation of power consumption of my system I want to do Post Place and Route simulation and generate the .vcd by doing so. I've made sure that there is data in BRAMs in system_stub_timesim.vhd file generated by ISE. But when modelsim simulates my design I observe irregular fetches on my address bus. Even the contents of the addresses which should be the opcodes of the instructions doesn't match with the assembly file that I have. I'm also monitoring Program Counter value but that one too has irregular patterns in addresses though different from address bus. I'm trying to verify my simulation to make sure that the .vcd file that is generated is what it should be however I'm stuck here because I don't know what the problem is. I am wondering if any of you have any idea what is going on and what can I do about it, I really appreciate your response and thanks alot beforehand, Amir PS. By the way I'm using ISE 8.1.03i and EDK 8.1.01i and Modelsim SE 6.0Article: 105140
Christian,
if you don't have multiple masters arbitration you can have a latency of
2 opb clks, please take a look at the opb_gpio logic (vhdl) to see how
the GPIO_xferAck is generated (in two clks)
not sure from where the 10-15 clk of latency are coming
Aurash
Christian Schleiffer wrote:
>Hej,
>
>thanks for the answer.
>
>
>
>>The FSL is just a simple set of FIFOs . You would need some kind of
>>state machine to read data out (and write to) these fifos. Yes, you
>>could also have some logic generate an IRQ when the FIFO is Full, Etc.
>>
>>
>
>The hardware interface is no problem at all and my bus connection will
>have a system synchronous part as well. Maybe I even don't have to worry
>about IRQs: the controller will be running uCLinux and I just read about
>an official FSL driver doing the polling job. I have to get deeper into
>that uCLinux stuff first, I think.
>
>
>
>>As far as data rate, The read and write FIFO is synschrounous to your
>>microblaze clock. I think it is a single cycle instruction to to a
>>non-blocking write to a FSL. Could take 2 or more but I can't remember.
>>
>>
>
>Yes, non-blocking write and read operations take 2 instruction cycles.
>
>
>
>> The rest of the speed is dependent our your state machine to grab data
>>about of the FIFO and move it elsewhere. It would have been really nice
>>for xilinx to put in an instruction (OR EVEN A FLAG) to tell me if there
>>is data in the read fifo.
>>
>>OPB is slow 10-15 clks per transaction. It is useful though, and simple
>>
>>
>
>That's a little slow since I have additional latency in the attached bus
>interface and on the software side. Too bad, the memory mapped IO
>approach would have been quite nice...
>
>
>
>>if you use the IPIF template. If you wish to do OPB master transactions
>>from a peripheral on the bus, I would recommend just reading the OPB
>>spec and making your own piece of IP.
>>
>>-Eli
>>
>>
>
>Bye
>/Chris
>
>--
>Christian Schleiffer
>Communication Security (COSY)
>Dept. of Electr. Eng. & Information Science
>Ruhr-University Bochum, Germany
>http://www.crypto.rub.de
>cschleiffer@crypto.rub.de
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 105141
On 14 Jul 2006 05:48:43 -0700, Weng Tianxiang
<wtxwtx@gmail.com> wrote:
>1. I would like to know why you get 543 compare/swap blocks?
>
>It has (lg N)*((lg N)+1)/2 stages based on formula of Knuth Vol 3,
>p.113. For N= 64, it has 21 stages.
Yes, that's where I get my figure for 21 levels of logic.
>With n/2 comparators at each stage, it means it has 32 comparators at
>each stage.
>
>32*21 = 672 /= 543?
Not all levels have the maximum population of n/2 blocks.
>2. How did you get the conclusion: the longest path goes through 21 of
>these blocks.
By counting them :-) See Knuth's algorithm. The little console-
mode C program, attached, implements the algorithm and shows you
the sorting network as ASCII-art. Make sure its output is rendered
in a fixed-width font.
I think it would be quite easy to modify the program
so that it writes a VHDL or Verilog netlist.
>I think because it is pipelined, the longest path goes through only 1
>block, why it is 21 blocks?
Of course, if you pipeline it then you can reduce the critical path
to only one level of compare/swap - but you then get 21 clocks
of latency. Your choice.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Batcher's merge-exchange sort
// Follows notation in Knuth, Sorting and searching, p112
//
// This is (nearly!) the best way to create a purely combinational
// sorting network, given that the basic available sorting operation
// is to compare two values and swap them if they are out of order.
// The hardware structures created by this program are easy to
// implement, and can readily be pipelined to improve throughput.
//
//
// Revision info:
//
// 1.0 Jonathan Bromley 18 Feb 2001
// first version
// 2.0 Jonathan Bromley 31 Jan 2002
// - improved argc/argv checking
// - added "usage" message if user supplies bad arguments
// - added statistics line
// - improved comments
// There's still a problem with wasteful use of space on
// lines where compare/exchange operations overlap.
// The program shows the correct set of swap operations,
// but it prints them in a slightly clumsy way in some situations.
// To fix this, we would need to gather up all the swaps
// at any given logic level, and sort them before printing.
// I can't be bothered doing that just now.
#include <stdio.h>
#include <stdlib.h>
// find /lg2(n)\, i.e. number of bits needed to represent 0..n-1
//
int ceil_lg2(int n) {
int t=1;
n--;
while (n/=2) t++;
return t;
}
// print separator between sets of compare/exchange
//
void sep(int n, int p, int q, int r, int d) {
int i;
printf("p,q,r,d = %2d,%2d,%2d,%2d |", p,q,r,d);
for (i=1; i<n; i++) printf("-|");
printf("\n");
}
// Compare/exchange.
// Pro tem, it just prints a little graphic - no calculation.
// Arguments:
// n number of input elements (decides width of printed line)
// a,b index numbers of the two elements to compare/exchange
// Call with a=0 to print the trailing part of the line.
//
void compex(int n, int a, int b) {
int t; // swap a,b if necessary
static int i=0; // keeps track of how much of the
// current line is already occupied with text
if (i>=a) {
// Overlap! We need to start on a new line.
// Print to the end...
while (++i <= n) printf(" |");
printf("\n");
i=0; // Be sure to print the start of the next line
}
if (a>0) {
// Make sure a, b are in order (paranoia!!)
if (a>b) {
t=a;
a=b;
b=t;
}
// Leading spaces (left margin)
if (i==0) printf(" ");
// Move forward to the starting position, printing blanks
while (++i < a) printf(" |");
// Print starting position
printf(" O"); // leaves i==a
// Move forward to the end position, printing links
while (++i < b) printf("==");
// Print end position
printf("=O"); // leaves i==b
}
}
// Print statistics info
//
void stats(int c, int l, int n) {
printf("\nSorted %d elements using:\n", n);
printf("%4d levels of logic;\n", l);
printf("%4d compare/exchange modules.\n\n", c);
}
// Main program
//
void Batcher( int N ) {
// Variables required by Batcher's algorithm.
// The very short names exactly match the names of
// variables in Knuth's description.
int t, p, q, r, d, i;
// Keep track of how many compares we did, and how many levels
// of logic it required
int comps=0;
int levels=0;
// M1: initialise p
t = ceil_lg2(N);
p = 1 << (t-1);
do {
// M2: initialise q,r,d
q = 1 << (t-1);
r = 0;
d = p;
do {
// M3: loop on i
sep(N,p,q,r,d);
levels++;
for (i=0; i < N-d; i++) if (( i & p ) == r) {
// M4: loop body
// Do a compare/exchange on the two elements.
compex(N, i+1, i+d+1);
comps++;
}
// Print any leftover bits of a line that we may need.
compex(N,0,0);
// M5: loop on q
i = q; // needed for "while" test!
d = q - p;
q /= 2;
r = p;
} while (i != p);
// M6: loop on p
} while (p /= 2);
// Tidy up and print statistics
stats(comps, levels, N);
}
// Command line driver
//
int main(int argc, char **argv) {
int n;
// Check the user supplied just one argument, a positive integer.
// If not, print usage message and exit.
if (
(argc != 2) // wrong number of args
|| ((n = atoi(argv[1])) <= 0) // arg isn't a positive int
) {
printf("BATCHER: Create a merge/exchange sort network.\n");
printf("=======\n");
printf("Usage:\n batcher <n>\n");
printf("<n> is the number of items to be sorted\n");
return 1;
}
// Command line had the correct form; go ahead.
printf("\n");
Batcher(n);
return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 105142"Ron" <News5@spamex.com> wrote in message news:zaHtg.779$RP7.677@fe02.lga... > rickman wrote: >> I think if upper management saw all of the posts that Austin makes they >> would likely not be pleased by the way the company is presented. Or >> maybe they wouldn't have a problem, I can't say. I do know that the >> apperence is that Xilinx is a rather arrogant company, not unlike Intel >> in the early days. > > I totally agree and already reported both Austin and Peter to Xilinx > marketing as well as corporate management sometime ago via email. It > seemed to do no good whatsoever, so maybe Xilinx doesn't care. ...Or maybe > they just need more complaints, preferably via US postal mail on company > letterhead rather than email. Austin sure spews a lot of marketing hype > for an engineer who is ostensibly not in marketing. > > -- Ron Resurrecting an old thread while so many people are off to vacation? This forum would have significantly less traffic and the general quality of information and help exchanged on this board would suffer if those two Xilinx employees were told to stop posting here. Austin can be as annoying at times when he's gung-ho about communicating the things *he* believes in; they may seem like total marketing rubbage but it seems to me he just has strong feelings on the matters. His interaction can be caustic at times as well. But taking the good with the bad his presence here has been invaluable, in my humble opinion. Why you have issues with Peter Alfke is beyong me. Not only is he professional, resourceful, and extremely helpful but he presents himself here calmly and conservatively even in the face of dire flames and worse. If more people could present his professionalism and the strong desire to help that both these men contribute to this forum, I would be a happier engineer. I'm glad that I only have one person in my kill file considering how long I've been interacting with the newsgroup. Feel free to add Ausitn, Peter, even myself to your own kill file. Many thanks to all the others who help make this a constructive place to advance FPGA design. - John HandworkArticle: 105143
> When you claim your FPGA solution will process 4096 bits of data per clock > cycle questioning how your solution gets 4096 bits of data per clock cycle > in and out of the FPGA makes a lot of sense. Yes, I see what you're saying now. I didn't realize I had claimed to be running that fast currently. I was talking about parallelizing the data once it was inside the chip -- some kind of serial to parallel operation. That's what I do currently. Still, I think 4096 bits per clock cycle is possible on a v5 using 533MHz LVDS input with 512 pin pairs should allow you to run the search algorithm at 66MHz. If you layed out the board well, you should be able to run some DCI DDR stuff at 266MHz using the newer chips. That's not out of spec, is it? I thought the DDR2 memory ran that fast. Currently my fastest input is 512bits at 66MHz.Article: 105144
<apologies to those who hate responses without context; please look up the thread if you don't know what I'm responding to> Some general tricks, then: I've sometimes doubled the write-side bandwidth in the Xilinx BlockRAM and used the "NO_CHANGE" WRITE_MODE to do a read at the clkX1 rising edge and a write at the clkX1 falling edge. I get the full cycle for the read value to get to its destination and a full cycle for the read address to get to the BlockRAM (albiet through a final read/write address mux stage), effectively making my port look like a read-only port working at clkX1 rather than a rd/wr port at clkX2. The cost of adding the multi-cycle constraints in the right places is minor compared to getting the "additional" write port. While looking into what it'd take to sort 1M 64-bit numbers, I figured the more numerous, smaller memories in the Altera Cyclone-II might give an edge but found lack of support for true dual-port operation for greater than 18 bits. In your application, the psuedo dual-port may be enough to get by with but it's up to you. The Lattice ECP2 family has 18 kbit memories that are also limited to 18 bits in true dual port, similar to the 4.5 kbit Altera memories. I think we've all experienced delays getting data back out of memory. I was surprised that the 3rd part IP core I evaluated on the Spartan3 was having severe timing troubles in the Altera device a coworker was using; he eventually worked out the timing but a bit late for the project; just a caveat for designs that are pushing speed - look over real implementations if you need high memory performance. - John_HArticle: 105145
> Can you release your design running frequency for 64*64 bitonic sorting > and what type of Xilinx chip or larger is to be used? So here are my results. First, I've never ran 64x64. I didn't mean to imply that I could -- just that it was possible. I can run at 100MHz on a 2v6000 with 16x64bit. It should run twice that fast on a V4. I compiled a 32x64bit and got this result: 50837 LUTs and 72720 FFs. That's larger than my chip. I compiled the 64x64bit version and got 140461 LUTs and 199888 FFs. That's pretty darn big. It includes registers for parallelizing the input which is coming in at 64bits per clock for those examples. I'm sure my implementation is not the most efficient possible, but I still think you'll need a pretty large chip to do any kind of serious parallel sorting.Article: 105146
"Noway2" <no_spam_me2@hotmail.com> wrote in message news:1152882298.931106.231460@i42g2000cwa.googlegroups.com... > > Thomas Reinemann wrote: >> Hello, >> >> usually a reset signal is applied to put the FFs of an FPGA into a known >> state. Just some days ago I had a discussion. Someone's point of view >> is, that a reset is not necessary, since the FF's output will be always >> zero, after applying the voltage. Does this happen in FPGAs really, >> especially in a Spartan3? >> >> Bye Tom > > 1 - If it were guarenteed that logic would always come up in a known > and valid state, why would the manufacturer include pins that are > dedicated to being a global reset? Does most logic power up into a > known and valid state or does it need a solid reset signal? > 2 - What about a brown out condition that scrambles the logic. Does > the device contain a built in power supply monitor that detects the > brownout and asserts a proper reset? > 3 - what about an application where a processor or other system needs > to control the timing of the reset or wants to reset the circuit on > watchdog timeout? > 4 - Would you rather be safe or sorry? If you have a design that doesn't *need* an unusual reset - just a power-on reset - then you can get by without it. If your system is subject to conditions that need to reset the logic, you can include the reset or just reprogram the FPGA (with the associated time lag and normal configuration issues). It may be improtant to note that the reset will not affect the contents of memories, distributed or otherwise. The global reset has been in the chips from the beginning (ASICs have their resets for good reason, the FPGAs carried this along) but ARE NOT RECOMMENDED for normal use because of the excessively long delays for those signals. The operation with a PLL/DLL is moot if your device waits until the loop is stable before coming in to operation. Not all synthesizers let you conveniently set the initial states of registers and memories. To get good RTL simulation, the age-old async reset may give you the match between simulation and synthesis that can easily cut a couple days off the debug time for an FPGA. Some synthesizers do a great job using the synchronous set and/or reset (unavailable if you use the async reset) to give you a little extra density beyond just cascaded 4-input LUTs. Some synthesizers to a piss-poor job with the synchronous set/reset, tying up resources and increasing the overall delay in high-speed logic that just needs simple 4-input LUTs. So. Depending on the design and the synthesis tools, you can get by quite nicely without the power-up async reset that's left unused for the rest of the device operation. Regardless of whether you use an async reset, a synchronous system reset, or no reset at all, you are only as safe as your engineering is thorough. - John_HArticle: 105147
Symon wrote: > Hi Rick, > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:1152845614.243674.222440@s13g2000cwa.googlegroups.com... > > > > Now I am forced to use registered synchronous block rams. > > > And about time too! :-) > > > > Am I missing something about how to best use a block ram? Any other > > ideas on how to do the read without adding a clock cycle? > > > If you have the timing budget, (I guess you have if this is coming from an > old design) use your idea of a dual port ram with one port for write and one > for read, but clock the read half on the falling edge. Thanks for the idea. I had a glimmer of that idea, but I didn't take the time to follow it through. Since the registered address and data do not need to go through any logic on the way to the RAM and the data output from the RAM only goes through a minimal amount of logic (well, not tons anyway, just a 14 way multiplexor). I might be able to get away with a single port clocked on the opposite edge of the clock from the rest of the design. Then I can use the enable on the reads and save the bit of power, plus it will not affect the path to the address register and should run faster if the opposite clocking works ok on the data out path. I love simple solutions!Article: 105148
PeteS wrote:
> If you are, however, in an environment with lots of clocks and signals
> (pretty much the standard, one might think) you have to wait until the
> *system* is in a known state. The best way to do that is with a global
> reset. Then there's the time when a system controller needs to reset
> just the FPGA (quite common), so a local reset for that purpose is
> always a good idea [tm].
I agree.
It also makes accurate simulation easier.
> Just my $0.02
New total is $0.04
-- Mike Treseler
Article: 105149Gee, Thanks. (Austin for Austin) Peter is on vacation, so I will say thanks for him as well: Danke, Austin (for Peter)
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