Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Apr 8, 7:05=A0pm, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de> wrote: > Franck Y <franck...@gmail.com> wrote: > > Hello, > > I have a project where i have to implement a ring oscillator (3 not > > gates) using an altera DE2. > > But i am confronted to several problems. > > The voltage p-p is 128.2 mV and the Vavg is 3.308 V which seems that > > quartus has optmised 'a little too much' since i want to see the > > delay. > > Is there any way to disable the optimisation ? I have read and show on > > option 'wire keep_wire', but i did not manage to make it work ... Or > > maybe it is another problem. > > What "voltage p-p" is 128.2 mV? Is this something you observe at an output= ? > What frequency? What output standard? Aren't you overdriving the outputs b= y > far? Shouldn't you run with a much longer chain? Don't the gate in the > short chain get overloaded? > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-darm= stadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- I used an oscilloscope, i tried with a longer chain but apparently it has no effect, expect that it has to be odd number of NOT gate. I do not understand the "Don't the gate in the chain short chain get overloaded?" Moreover even if the ring oscillator should not have any power input, i wanted to put a low voltage( < 1.5V, but is is another problem since i do not have to possibility to add external power) Thanks again for your helpArticle: 131051
On Apr 8, 7:53=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Franck Y wrote: > > Hello, > > > I have a project where i have to implement a ring oscillator (3 not > > gates) using an altera DE2. > > But i am confronted to several problems. > > The voltage p-p is 128.2 mV and the Vavg is 3.308 V which seems that > > quartus has optmised 'a little too much' since i want to see the > > delay. > > > Is there any way to disable the optimisation ? I have read and show on > > option 'wire keep_wire', but i did not manage to make it work ... Or > > maybe it is another problem. > > > Thanks for your time, and help > > Try a longer chain, 3 seems very short, unless they are pin-buffers, > =A0 and you should ideally use alternate NOT and NOR gates with a reset > drive, in a ring oscillator. > > -jg Hello, I thought about the reset ! But i do have to put a VCC or a ground ? But i do that, my result will be wrong FArticle: 131052
Hello gentle readers,
I started playing with FPGA and verilog about a month ago. As a fun
starting project, my goal is to allow interaction between host linux pc
and fpga lcd display. The connection is made through serial RS323
interface. Here is my lcd controller module that accomplished my goal. I
am looking for your advice and suggestions and in what ways I can
improve this module. I am hoping to learn from this process. There are
some line folding problems during copy/paste, I tried my best to fix
them. There are some code snippets I copied from other modules as you
can see distinctively different styles of variable naming. I should fix
these style issues. (ise don't play well with vim //sigh).
module lcd_controller (clk, data_ready, rx_data, lcd_rs, lcd_rw, lcd_e,
lcd_4, lcd_5, lcd_6, lcd_7);
parameter k = 18;
parameter RegisterInputData = 1;
// in RegisterInputData mode, the input doesn't have to stay valid while
// the character is been transmitted
parameter clr = 8'h0A;
input clk; // synthesis attribute PERIOD clk "50 MHz"
input data_ready;
input [7:0] rx_data;
output lcd_rs;
output lcd_rw;
output lcd_e;
output lcd_7;
output lcd_6;
output lcd_5;
output lcd_4;
reg lcd_e, lcd_rs, lcd_rw, lcd_7, lcd_6, lcd_5, lcd_4;
reg [k+8:0] count=0;
reg [6:0] lcd_code = 0;
reg [2:0] state=3'b000;
reg [2:0] next_state=3'b000;
wire lcd_ready = (state==1);
// store rx_data locally
reg [7:0] lcd_dataReg;
always @(posedge clk) if(data_ready & lcd_ready) lcd_dataReg <= rx_data;
wire [7:0] lcd_dataD = RegisterInputData ? lcd_dataReg : rx_data;
// continuous assignment by default of wire type, 'H' clears display
wire clear = (rx_data == clr)? 1:0;
// sequential logic
always @ (posedge clk)
begin
state <= next_state;
if(state != 3'b001)
begin
count <= count + 1;
if(count[4] && state == 3'b010)
count <= 0;
if(count[4] && state == 3'b100)
count <= 0;
if(count[5] && state == 3'b011)
count <= 0;
if(count[10] && state == 3'b101)
count <= 0;
end
else
count <= 0;
{lcd_e,lcd_rs,lcd_rw,lcd_7,lcd_6,lcd_5,lcd_4} <= lcd_code;
if(state == 0 || state == 6) lcd_e <= ^count[k+1:k];
end // sequential logic
// combinatorial logic
always @ (state or count or data_ready or clear) begin
case(state)
3'b000:
begin
if(count[k+5:k+2] == 12)
next_state <= 3'b1; // idle_data/1
else
next_state <= 0;
end
3'b001:
begin
if(data_ready) begin
if(clear)
next_state <= 3'b110;
// clear/6
else
next_state <= 3'b10;
// disp_hn/2
end
else
next_state <= 3'b1; // idle_data/1
end
3'b010:
begin
if(count[4])
next_state <= 3'b11; // idle_high/3
else
next_state <= 3'b10; // disp_hn/3
end
3'b011:
begin
if(count[5])
next_state <= 3'b100; // disp_ln/4
else
next_state <= 3'b11; // idle_high/3
end
3'b100:
begin
if(count[4])
next_state <= 3'b101; // wait/5
else
next_state <= 3'b100; // disp_ln/4
end
3'b101:
begin
if(count[10])
next_state <= 3'b1; // idle_data/1
else
next_state <= 3'b101; // wait/5
end
3'b110:
begin
if(count[k+3:k+2] == 2)
next_state <= 3'h1; // idle_data/1
else
next_state <= 3'h6; // clear/6
end
endcase
end // combinatorial logic
// output logic
always @(state or count or lcd_dataD) begin
lcd_code <= 7'h00;
case(state)
3'b000:
begin
case (count[k+5:k+2])
0: lcd_code <= 7'h43;// power-oninitialization
1: lcd_code <= 7'h43;
2: lcd_code <= 7'h43;
3: lcd_code <= 7'h42;
4: lcd_code <= 7'h42; // function set
5: lcd_code <= 7'h48;
6: lcd_code <= 7'h40; // entry mode set
7: lcd_code <= 7'h46;
8: lcd_code <= 7'h40; // display on/off
9: lcd_code <= 7'h4C;
10: lcd_code <= 7'h40; // display clear
11: lcd_code <= 7'h41;
endcase
end
3'b001:
lcd_code <= 7'h00;
3'b010:
lcd_code <= {3'b110, lcd_dataD[7:4]};
3'b011:
lcd_code <= 7'b0110000;
3'b100:
lcd_code <= {3'b110, lcd_dataD[3:0]};
3'b101:
lcd_code <= 7'b0110000;
3'b110:
begin
case(count[k+3:k+2])
0: lcd_code <= 7'h40; //displayclear
1: lcd_code <= 7'h41;
endcase
end
endcase
end // output logic
endmodule
Article: 131053On 4$B7n(B8$BF|(B, $B>e8a(B9$B;~(B32$BJ,(B, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > grant0920 wrote: > > Hi! everyone > > > I have a very basic problem. I know that the 6-position DIP switch on > > the ML403 board can control the configuration address and FPGA > > configuration mode. On the ML310 board, I am not sure where can set > > the FPGA configuration mode. I want to set the configuration mode of > > my ML310 borad as the SelectMAP mode. Please tell me how to set its > > FPGA configuration mode. Thanks very much! > > This can't be done. There is no support for SelectMAP configuration > on the ML310. > > Ed McGettigan > -- > Xilinx Inc. Thanks very much for your kindly reply. So, where can I chage the configuration mode on the ML310 if I want to use the ICAP to configure my design? I want to change my configuration mode except for the boundary scan mode. Thanks!Article: 131054
Franck Y <franck110@gmail.com> wrote: .. > I do not understand the "Don't the gate in the chain short chain get > overloaded?" ... You probably drive the gates in the linear region, where a lot of current is flowing through the upper PMOS and lower NMos transistor. While this current also flows during normal switching, this switching happens at a lower frequency, resulting in lower effective current flow through tghe inverter. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 131055
On 2008-04-08, Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: > B.t.w two questions: > - can anybody give an example commandline for a real world DATA2MEM > example? I have one example of this in my PPC405 design at http://www.da.isy.liu.se/~ehliar/stuff/ppc405-mini-v1.0.tar.gz (No EDK required to test it.) /AndreasArticle: 131056
On Tue, 8 Apr 2008 06:01:33 -0700 (PDT), Antti <Antti.Lukats@googlemail.com> wrote: >On 8 Apr., 14:59, Petter Gustad <newsmailco...@gustad.com> wrote: >> Antti <Antti.Luk...@googlemail.com> writes: >> > On 8 Apr., 13:22, Petter Gustad <newsmailco...@gustad.com> wrote: >> >> Antti <Antti.Luk...@googlemail.com> writes: >> >> > a DATA2MEM (elf to bit file merge) is VERY important for softcore >> >> > processors in FPGA's, and Altera kinda claims they have NIOS and >> >> > stuff, but the MOST IMPORTANT too for FPGA-soc is missing from their >> >> > toolchain!! >> >> >> You can get the same functionality using >> >> >> quartus_cdb --update_mif >> > to my knowledge YOU CAN NOT >> >> > if Quartus has generated a bit file (programming file) >> > then this file (without access to the project database) CAN NOT BE >> > updated with new memory file, unlike it is possible with xilinx >> > data2mem tool >> >> If you have lost track of the source/project database (like the OP) >> you can not. But for the functional purpose where you run make on you >> NIOS software project and merge the generated mif/hex file into a new >> sof file without recompiling the project you can. >the all IDEA about the update is that you need 2 files > >1) BIT file >2) ELF file > >and nothing else.. if based on those 2 files the elf can not be >merged, then this is REALLY BAD!!! Well, I thought I needed the .bmm file too, any time I've tried it. How do you map addresses and data slices into specific BRAMs otherwise? So 3 files, one of which comes from the original project. But it's just a straightforward text file. - BrianArticle: 131057
Tks Adam. I started to play with it... looks indeed not too difficult. lc. Górski Adam wrote: > - Just run SOPC Builder > - make a system with nios ii , internall ram and for example port i/o. > - generate system > - put generated system into top schematic > - build fpga image > - load to fpga > - run Nios ide > - and have some fun > > That's all > > Adam > > >> Would it be possible to have a bit more details >> on how to, just to ease my learning curve. > >>> Yes, you can work with internal ram only. >>> Yes you can store program in configuration memory used for FPGA. >>> >>> I tested. > >Article: 131058
Tks. David. What is the trick to get the program uploaded to RAM and run it without re-synthesis ? Is that within the NIOS ide ? Or should I go back to quartus for some operation ? That is certainly the way to go while testing and debugging the code. Thanks. Luis c. David Spencer wrote: >> Hi, >> >> Yes, you can work with internal ram only. >> Yes you can store program in configuration memory used for FPGA. >> >> I tested. >> >> Adam > > Or you can store the program in internal RAM (functioning as ROM) too for a > fully self-contained system. To make this easier, there is a mechanism to > update the RAM initialization contents without needing to do a full > re-synthesis and PAR each time. > > If you use SOPC Builder it is trivial to set this up. > >Article: 131059
Hi Luis, 1 ) You can run " Processing -> Update memory initialization file " and then "Processing -> Start Assembler" to update fpga image file with lastest NIOS code. 2) You can use also EPCS controller module (SOPC Builder ) This is a little bit more complex. Just set start vector of your nios procesor to EPCS controller and build all again. And finally use from Nios IDE "tools->Flash Programmer .." to program both *.sof and *.elf file Adam > Tks. David. > What is the trick to get the program uploaded > to RAM and run it without re-synthesis ? > Is that within the NIOS ide ? Or should I go > back to quartus for some operation ? > That is certainly the way to go while testing > and debugging the code. > > Thanks. > Luis c. > > > David Spencer wrote: >>> Hi, >>> >>> Yes, you can work with internal ram only. >>> Yes you can store program in configuration memory used for FPGA. >>> >>> I tested. >>> >>> Adam >> >> Or you can store the program in internal RAM (functioning as ROM) too >> for a fully self-contained system. To make this easier, there is a >> mechanism to update the RAM initialization contents without needing to >> do a full re-synthesis and PAR each time. >> >> If you use SOPC Builder it is trivial to set this up. >>Article: 131060
Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> writes: > B.t.w two questions: > - can anybody give an example commandline for a real world DATA2MEM > example? It's been a while (don't have access to ISE at the moment), but I've usually done this through bitinit, something like: bitinit system.mhs -bm system.bmm -pe ppc405_0 executable.elf -bt old.bit -o new.bit Somebody else probably have a similar data2mem command laying around somewhere. > - can any FPGA family BRAM be written by JTAG directly without > upsetting the rest of the FPGA configuration? That's what I normally do with the NIOS software. It depends on how your application will handle that your software is replaced with a new version on-the-fly. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 131061
Is task in verilog equivalent to procedure in VHDL? I am trying to convert a verilog file to vhdl. Verilog => // string data type reg [8*4:1]a; reg [8*255:0]b; VHDL => Is the above equivalent to variable a : string(1 to 8*4) variable b : string(1 to 8*255)Article: 131062
Many thanks for the very helpful guidelines. Luis C. Górski Adam wrote: > Hi Luis, > > 1 ) You can run " Processing -> Update memory initialization file " and > then "Processing -> Start Assembler" to update fpga image file with > lastest NIOS code. > > 2) You can use also EPCS controller module (SOPC Builder ) > This is a little bit more complex. > Just set start vector of your nios procesor to EPCS controller and build > all again. > > And finally use from Nios IDE "tools->Flash Programmer .." to program > both *.sof and *.elf file > > > Adam > >> Tks. David. >> What is the trick to get the program uploaded >> to RAM and run it without re-synthesis ? >> Is that within the NIOS ide ? Or should I go >> back to quartus for some operation ? >> That is certainly the way to go while testing >> and debugging the code. >> >> Thanks. >> Luis c. >> >> >> David Spencer wrote: >>>> Hi, >>>> >>>> Yes, you can work with internal ram only. >>>> Yes you can store program in configuration memory used for FPGA. >>>> >>>> I tested. >>>> >>>> Adam >>> >>> Or you can store the program in internal RAM (functioning as ROM) too >>> for a fully self-contained system. To make this easier, there is a >>> mechanism to update the RAM initialization contents without needing >>> to do a full re-synthesis and PAR each time. >>> >>> If you use SOPC Builder it is trivial to set this up. >>>Article: 131063
On Apr 8, 6:53 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Franck Y wrote: > > Hello, > > > I have a project where i have to implement a ring oscillator (3 not > > gates) using an altera DE2. > > But i am confronted to several problems. > > The voltage p-p is 128.2 mV and the Vavg is 3.308 V which seems that > > quartus has optmised 'a little too much' since i want to see the > > delay. > > > Is there any way to disable the optimisation ? I have read and show on > > option 'wire keep_wire', but i did not manage to make it work ... Or > > maybe it is another problem. > > > Thanks for your time, and help > > Try a longer chain, 3 seems very short, unless they are pin-buffers, > and you should ideally use alternate NOT and NOR gates with a reset > drive, in a ring oscillator. > > -jg 3 is probably fine, if they are placed fairly far apart. Quartus is probably placing them in the same LAB, where the delay between flops will be exceedingly small. Manually placing them in the corners should increase the delay long enough to actually see some ringing. Turn on logic lock for the path, and it should be very predictable between fittings.Article: 131064
On Apr 7, 6:18 pm, n...@puntnl.niks (Nico Coesel) wrote: > Something that would be really nice is a parallel port programmer. > With a huge twist... Years ago I've build an eprom emulator which > simply simulates a printer. Configuring it is a matter of printing > text commands. Downloading the hex file is simply a matter of printing > it. No device drivers whatsoever are required. It will work with USB > to parallel converters (including the crappy ones). There is full flow > control as well and it is bleeding fast. It amazes me no-one ever came > up with something like that. Shouldn't be too hard for passive serial / slave serial modes - just a little logic on the LPT strobe and 1 data bit (using all bits and a shift register would be tempting, but then you'd need an appropriate local clock, the speed of which may need to detect the strobe speed somehow). Where this breaks down is trying to do JTAG when you don't know the commands - for example, trying to run one of Altera's JAM files that's looking for a response beyond just monitoring a status bit infrequetly. Also, in this day and age, simply dumping strobed bytes out the LPT is going to require a driver. And a USB to parallel converter is going to require a driver... Figure that you may still need some level translation, and something based on a cypress fx2 USB micro may make more sense.Article: 131065
Hi all ! I'm wondering if a basic tool already exist to program Xilinx CPLD (XC95144 and so) under Linux (preferably with the old Parralle cable III) Thanks, Habib. -- HBVArticle: 131066
Habib Bouaziz-Viallet <habib@rigel.systems> writes: > I'm wondering if a basic tool already exist to program Xilinx CPLD > (XC95144 and so) under Linux (preferably with the old Parralle cable III) Doesn't ISE itself have such a tool? If all else fails, you can port the sample app in xapp058 to whatever hardware you have. I've done that with a USB adapter[1] to program an XC9572XL[2] with FC6. [1] http://www.delorie.com/electronics/usb-gpio/ [2] http://www.delorie.com/electronics/bin2seven/Article: 131067
On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote: > "Dave" <dhsch...@gmail.com> wrote in message > > news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.com... > > > > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > >> <shakith.ferna...@gmail.com> wrote in message > > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com... > > >> > Hi, > > >> > We have developed a High Speed on FPGA using the MGT/RocketIO to > >> > generate high speed signals. Also we receive the high speed signals > >> > using the MGT. Due to the nature of the application, we require a pure > >> > signal without encoding (We have switched off the 8B/10B encoding in > >> > the MGT). The problem is that it effects the clock recovery accuracy > >> > in the received signal as there might not be good DC balance in the > >> > signal. Which in turn effects the data received. And MGT is a black > >> > box to us. > > >> > Two options- > >> > 1. Another encoding mechanism such that we have pure signal and good > >> > clock recovery. > >> > 2. Or is there a parameter in MGT to improve the clock recovery. > > >> > We are looking for some solution around this problem. > > >> > Our setup: > >> > FPGA - Xilinx Virtex II Pro > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System > >> > Software - ISE 9.1i > > >> > Best Regards > >> >Shakith > > >> The clock recovery circuitry requires that there be a minimum number of > >> received edges per unit time. Otherwise, the recovered clock edges will > >> drift with respect to the data stream. > > >> If you don't use some type of encoding (e.g. 8B/10B), or you don't insure > >> that your raw data ALWAYS provides this minimum edge density requirement, > >> then the clock/data recovery circuitry will not work. > > >> Bob > > > Perhaps a scrambler/descrambler using LFSR's would help alleviate any > > edge density or DC bias problems by randomizing the data a bit? I'm > > not sure if it would guarantee correct reception, but it may help. > > You don't say why you need a "pure" signal (no coding). I could assume that > you are trying to eliminate the overhead of coding (with 8b10b you only get > an effective data bandwidth of 80%). > > You didn't say whether or not you MUST have a DC-balanced signal. Are your > transmitters AC-coupled to the receivers? If yes, the you must have a > DC-balanced signal and coding IS required. > > You also don't mention your clocking requirements. Do you have a common > (distributed) reference clock, or are the reference clocks independant? > > Typical clock recovery circuits assume plesio-synchronous operation. This > means the the reference clocks can be independent but must be within +/- XYZ > PPM (parts-per-million) of each other. For a receiver to track the > transmitter the receiver must recover the clock (and data) from the > transmitted bit stream. At high speeds this is done using PLLs. For the PLLs > to perform well they require frequent edges in the transmitted bit stream. > > Without a coded bit-stream you can't have DC-balance and you can't gaurantee > frequent edges for the PLL. So if you really can't have a coded bit-stream > then you must have a distributed (common) reference clock and you cannot use > AC-coupling. > > If you are trying to minimize the overhead of coding look at other coding > methods like 64b/66b codes. These are more efficient but still have the > benefits of DC-balanced tranmission and frequent clock edges. > > Note that another benefit of 8b10b is the ability to align your symbols. How > are you going to know the boundaries of a byte, a packet, etc., without a > coded stream and use of non-data symbols (control symbols)? If you have > independent reference clocks how are you going to avoid underrun and overrun > of the reciever withouth control symbols (i.e. insertion and removal of idle > characters)? Do you need any form of closed-loop flow control, error > signalling, etc.? If yes, how are you going to do this without control > symbols? > > TC Thanks...we also noticed a new problem When we run our implementation on FPGA, there is loss of data on the non-active part of the signal. Its set to be 20180bits, but the number of bits received is less than that. The loss of data is not consistent either. But this doesn't appear in simulation in Modelsim. One reason could be the fact that the DC Balance is not there. But does it affect the data recovery from serial to parallel? Another option is use an external modulator chip on the receiver signal to achieve DC balance and the use the new modulated signal on MGT and decode it inside the FPGA. Our setup: MGT Speed - 2 Gpbs FPGA - Xilinx Virtex II Pro Board - Xilinx XUP Virtex(tm)-II Pro Development System Software - ISE 9.1iArticle: 131068
Le Wed, 09 Apr 2008 12:49:43 -0400, DJ Delorie a écrit: > Habib Bouaziz-Viallet <habib@rigel.systems> writes: >> I'm wondering if a basic tool already exist to program Xilinx CPLD >> (XC95144 and so) under Linux (preferably with the old Parralle cable III) > Hi ! It's always a pleasure to speak with you M. Delorie > Doesn't ISE itself have such a tool? I'm working with WebPack ISE and i guess that the programming tools (ImpACT) is a native MS-Windows tool and did not work under GNU/Linux. I'm building a parallel cable for my own so i did not already test it. > If all else fails, you can port the sample app in xapp058 to whatever > hardware you have. I've done that with a USB adapter[1] to program an > XC9572XL[2] with FC6. I will take a look to this xapp058. Many thanks. > > [1] http://www.delorie.com/electronics/usb-gpio/ [2] > http://www.delorie.com/electronics/bin2seven/ -- HBVArticle: 131069
Symon, I read the patent(s). I am amazed at how useless this is: use of a MEMS to detect the charge cloud.... OK, so there went a neutron. OK. Did it upset one of my 512K bits in my cache? Did it upset a register? .... So, they have a number of patents for this, and it is interesting (as a physics experiment), but then, so is: http://www.google.com/patents?id=bQd-AAAAEBAJ&printsec=abstract&zoom=4 or http://www.google.com/patents?id=uOs2AAAAEBAJ&printsec=abstract&zoom=4 Interesting science, bad PR! A much better patent to crow about: http://www.google.com/patents?id=whEPAAAAEBAJ&printsec=abstract&zoom=4&dq=intel+soft+error+correction+logic+and+memory AustinArticle: 131070
shakith.fernando@gmail.com wrote: (snip, someone wrote) >>>>The clock recovery circuitry requires that there be a minimum number of >>>>received edges per unit time. Otherwise, the recovered clock edges will >>>>drift with respect to the data stream. >>>>If you don't use some type of encoding (e.g. 8B/10B), or you don't insure >>>>that your raw data ALWAYS provides this minimum edge density requirement, >>>>then the clock/data recovery circuitry will not work. > Thanks...we also noticed a new problem > When we run our implementation on FPGA, there is loss of data on the > non-active part of the signal. Its set to be 20180bits, but the number > of bits received is less than that. The loss of data is not consistent > either. But this doesn't appear in simulation in Modelsim. One reason > could be the fact that the DC Balance is not there. But does it affect > the data recovery from serial to parallel? It does if you are doing clock recovery on the incoming bits. If the clock is off, it will miscount on long runs of the same bit. -- glenArticle: 131071
I've noticed that the Xilinx FFT bit-accurate c simulation calls are very very slow. Anyone else notice this? I am working on hybrid fixed/floating-point digital signal processing application, and I frequently make calls to the bit-accurate simulation function (anywhere on the order of 1,000 times, to 1,000,000 times per run). As I'm attempting to run longer simulations, the runtime is becoming my critical path. The program is single-threaded right now, and I intend to write a multi-threaded version soon. But first, I decided to use a profiler on my single-threaded code to see what kind of speedup I should expect. I wasn't very surprised to find that 99% of my execution time was taking place inside the xilinx_ip_xfft_v5_0_bitacc_simulate() function. I WAS surprised to find that 55.6% of that function's execution time is being spent in malloc() and free() calls. I have some nice call graphs and an excel spreadsheet I'd be willing to share if someone from Xilinx would like to take a look. Why not move all of the memory allocations into the "create" and "destroy" state calls of the program? If this were done, all memory allocations could be performed once, when the state were created. A speedup of over 2x could be realized with those changes to the function. On top of that, I fear that multi-threading my code won't lead to very much speedup, due to the spin-locks in the heap allocation kernel calls. Now before anyone replies to this thread and says, "but that's a lot of memory allocations hanging around!" My reply: If a user is worried about running out of memory, they can create and destroy the state as needed. The memory is going to get allocated anyway. The only difference will be better control of how often the costly heap access kernel functions are called. I could see the memory possibly being wasted when simulating a core with a reconfigurable transform length. A pipelined 64K-point FFT would need roughly 1GB. At that point, however, the math complexity will probably start to eclipse the memory allocation penalties. I'd be more than happy to make the changes to the source myself, if someone from Xilinx were kind enough to share it. Cheers. Petersen Curt EM Photonics, Inc. Newark, DEArticle: 131072
Habib Bouaziz-Viallet <habib@rigel.systems> wrote: > Le Wed, 09 Apr 2008 12:49:43 -0400, DJ Delorie a écrit: > > Habib Bouaziz-Viallet <habib@rigel.systems> writes: > >> I'm wondering if a basic tool already exist to program Xilinx CPLD > >> (XC95144 and so) under Linux (preferably with the old Parralle cable III) > > > Hi ! > It's always a pleasure to speak with you M. Delorie > > Doesn't ISE itself have such a tool? > I'm working with WebPack ISE and i guess that the programming tools > (ImpACT) is a native MS-Windows tool and did not work under GNU/Linux. > I'm building a parallel cable for my own so i did not already test it. Use impact with http://rmdir.de/~michael/xilinx/ Don't bother with the windriver kernel module... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 131073
On Apr 8, 5:30 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > > Re Quad Serial memory devices, and execute in place : > I see SST have just released a Quad device as well. > $1.16/10K for 16MBit > > Good news, and bad news : > > Good news: 80MHz nibble rate. They also added 8 & 16 bit address modes, > to the default 24 bit. > Bad News: These short-jump modes _are_ signed relative, > BUT they do NOT cross page boundaries. (ie Just like the 8048...) > > So, the idea falls short of being usable in relocatable code. > > Pity, as a memory-opcode jump is a good way to save some bandwidth > > Why make something signed relative, but then have it page-wrap ? > > - was this a bug, maybe they intended it to work properly, but found > an oops, and changed the data to match the silicon ? I knew there was something fundamentally wrong with the idea of a very slow processor in an FPGA executing from an external memory chip. I figured out what it is. Using even *less* real estate inside the FPGA and by adding only two, very inexpensive chips, I can add an *external* processor and (optionally) a serial memory chip to interface with the FPGA through a serial port such as SPI, I2C or custom. Rather than try to implement a full processor in minimal gates, isn't it easier and more effective to use a serial control to allow an external processor to control the FPGA, while matching the size and cost to the job? Even 32 bit flash based ARM chips are available for less than the cost of the serial memory.Article: 131074
On Apr 9, 10:05=A0am, shakith.ferna...@gmail.com wrote: > On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote: > > > "Dave" <dhsch...@gmail.com> wrote in message > > >news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.com...= > > > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote: > > >> <shakith.ferna...@gmail.com> wrote in message > > > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com.= .. > > > >> > Hi, > > > >> > We have developed a High Speed on FPGA using the MGT/RocketIO to > > >> > generate high speed signals. Also we receive the high speed signals= > > >> > using the MGT. Due to the nature of the application, we require a p= ure > > >> > signal without encoding (We have switched off the 8B/10B encoding i= n > > >> > the MGT). The problem is that it effects the clock recovery accurac= y > > >> > in the received signal as there might not be =A0good DC balance in = the > > >> > signal. Which in turn effects the data received. And MGT is a black= > > >> > box to us. > > > >> > Two options- > > >> > 1. Another encoding mechanism such that we have pure signal and goo= d > > >> > clock recovery. > > >> > 2. Or is there a parameter in MGT to improve the clock recovery. > > > >> > We are looking for some solution around this problem. > > > >> > Our setup: > > >> > FPGA - Xilinx Virtex II Pro > > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System > > >> > Software - ISE 9.1i > > > >> > Best Regards > > >> >Shakith > > > >> The clock recovery circuitry requires that there be a minimum number = of > > >> received edges per unit time. Otherwise, the recovered clock edges wi= ll > > >> drift with respect to the data stream. > > > >> If you don't use some type of encoding (e.g. 8B/10B), or you don't in= sure > > >> that your raw data ALWAYS provides this minimum edge density requirem= ent, > > >> then the clock/data recovery circuitry will not work. > > > >> Bob > > > > Perhaps a scrambler/descrambler using LFSR's would help alleviate any > > > edge density or DC bias problems by randomizing the data a bit? I'm > > > not sure if it would guarantee correct reception, but it may help. > > > You don't say why you need a "pure" signal (no coding). I could assume t= hat > > you are trying to eliminate the overhead of coding (with 8b10b you only = get > > an effective data bandwidth of 80%). > > > You didn't say whether or not you MUST have a DC-balanced signal. Are yo= ur > > transmitters AC-coupled to the receivers? If yes, the you must have a > > DC-balanced signal and coding IS required. > > > You also don't mention your clocking requirements. Do you have a common > > (distributed) reference clock, or are the reference clocks independant? > > > Typical clock recovery circuits assume plesio-synchronous operation. Thi= s > > means the the reference clocks can be independent but must be within +/-= XYZ > > PPM (parts-per-million) of each other. For a receiver to track the > > transmitter the receiver must recover the clock (and data) from the > > transmitted bit stream. At high speeds this is done using PLLs. For the = PLLs > > to perform well they require frequent edges in the transmitted bit strea= m. > > > Without a coded bit-stream you can't have DC-balance and you can't gaura= ntee > > frequent edges for the PLL. So if you really can't have a coded bit-stre= am > > then you must have a distributed (common) reference clock and you cannot= use > > AC-coupling. > > > If you are trying to minimize the overhead of coding look at other codin= g > > methods like 64b/66b codes. These are more efficient but still have the > > benefits of DC-balanced tranmission and frequent clock edges. > > > Note that another benefit of 8b10b is the ability to align your symbols.= How > > are you going to know the boundaries of a byte, a packet, etc., without = a > > coded stream and use of non-data symbols (control symbols)? If you have > > independent reference clocks how are you going to avoid underrun and ove= rrun > > of the reciever withouth control symbols (i.e. insertion and removal of = idle > > characters)? Do you need any form of closed-loop flow control, error > > signalling, etc.? If yes, how are you going to do this without control > > symbols? > > > TC > > Thanks...we also noticed a new problem > When we run our implementation on FPGA, there is loss of data on the > non-active part of the signal. Its set to be 20180bits, but the number > of bits received is less than that. The loss of data is not consistent > either. But this doesn't appear in simulation in Modelsim. One reason > could be the fact that the DC Balance is not there. But does it affect > the data recovery from serial to parallel? > Another option is use an external modulator chip on the receiver > signal to achieve DC balance and the use the new modulated signal on > MGT and decode it =A0inside the FPGA. > > Our setup: > MGT Speed - 2 Gpbs > FPGA - Xilinx Virtex II Pro > Board - Xilinx XUP Virtex(tm)-II Pro Development System > Software - ISE 9.1i You are running into a fundamental limitation. What you receive is NRZ data, High for 1, Low for 0 (or something similar). You know that a High level of a certain duration means three ones in a row, but the receiver needs a clock to separate the bits. It gets this clock from its own PLL oscillator that is being kept alive and accurate by re- synchronizing itself from any transitions in the data stream. That's why you must have a transition quite often. Maybe you can run for 70 bits without a transition, but after tht, the PLL oscillator will drift and will not partition the incoming data stream properly. Sorry for this basic explanation, maybe everybody understands all this already. Peter Alfke
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