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
If you're sure your programming hardware is OK, then you probably have a bad bit stream. The FPGA won't raise done if the stream fails certain checks. Are you sure it's formatted correctly for the programming mode?Article: 100276
ALuPin@web.de wrote: > I want to know what approach you would recommend to > compress an incoming DVI data stream (data width 24 bit, pixel clock > 25-165MHz) > from 24 bit colour depth to 16 bit colour depth. > > Are there algorithms for parallel data processing (24bit/16bit) you > can recommend ? To reduce the color depth, you just throw away some of the low order bits of the color samples. To get from 24-bit to 15-bit, you throw away the low order three bits of each sample. For 16-bit, you can keep one extra bit of one of the colors; check the interface specs for 16-bit to see how the bits are allocated.Article: 100277
On Wed, 5 Apr 2006 05:25:59 -0700, ahakan <> wrote: >Thanks for your response, but I am using Parallel Cable IV, so I guess the problem is not due to the parallel cable (I tried the Platform Cable USB as well). I have the same problem from time to time with PCIV (not tried with other cables) and XC3S400. Sometimes it is just a momentary problem, you muts just try again and it programs OK. Sometimes it is plain stupidity of (I suppose) the FPGA, switch power off and on again, it usually works. Best regards, ZaraArticle: 100278
dale.prather@gmail.com wrote: > John, > Thank you for your input. It has helped tremendously. > > Hopefully, just one more question. When I do this: > > BUS_INTERFACE SFSL0 = my_fsl_incoming > BUS_INTERFACE MFSL0 = my_fsl_outgoing > > I get these two errors, which I think is at the root of the confusion. > > > ERROR:MDT - fsl_v20 (my_fsl_incoming) - > C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 197 - must > have > atleast 1 master assigned! > > ERROR:MDT - fsl_v20 (my_fsl_outgoing) - > C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 210 - must > have > atleast 1 slave assigned! > > For now, to fix it, I've done this: > > BUS_INTERFACE MFSL0 = my_fsl_incoming > BUS_INTERFACE SFSL0 = my_fsl_incoming > BUS_INTERFACE SFSL1 = my_fsl_outgoing > BUS_INTERFACE MFSL1 = my_fsl_outgoing > > Any comments on the errors or my solution? > > Thanks, > Dale > Hi, In your fix you have connect two outgoing FSL ports on MicroBlaze to two incoming FSL ports. So this MicroBlaze can send data to itself. Not sure if this is what you want to do. Since you want to connect to the outside world of EDK, the tools doesn't see a Master-Slave pair in your first attempt. It's the DRC of the tools that errors out. You can't use the BUS_INTERFACE for connect since their is no slave/master BUS_INTERFACE for them. You must connect each signal individual as John proposed in his first reply. GöranArticle: 100279
John_H wrote: > Jim Granville wrote: > >> John_H wrote: >> >>> Hello folks, >>> >>> I may be starting my first Altera design in a few years but I was >>> disappointed to find that the Cyclone-II LVDS drivers aren't true >>> differential drives: an external resistor network is needed to >>> produce proper LVDS levels like in the "old days." >>> >>> Does anyone here have experience with the LVDS drivers? I imagine >>> I'll end up with 0603 resistors rather than a Bourns network, for >>> instance. What have others used? >> >> >> >> You could use the quad-smd's = 4 resistors in 1206 or 0805 ? >> >> -jg > > > I could use "a Bourns network" or the like. I anticipate using 0603s > because they're small, available, routable. Unless there's experience > that says these tiny discretes should, indeed, be a resistor network > instead. > > I could use the quad-smd's. Is there a reason I should? Shouldn't? > > I'm hoping more for tidbits of experience rather than good ideas. Mainly it's a packing density issue. IIRC the pitch on the Quads, matches that of common TQFP packages. They are also on the right part of the price curve, and slash the resistor placement bill by 3/4. -jgArticle: 100280
Hi, thank you for your comments. The system is already working, so hardware should not be changed: 24bit display, 2 DDR Sdram memories @ 133MHz The 24bit-64bit adaption is no problem at all, adapting 16bit to 64bt would be even more comfortable. Andy, concerning the quality of the images through the "compression process" I can state that the system is used for PC desktop applications in most of the cases. Rgds Andr=E9Article: 100281
sorry the delay in timing simulation was due to
default value of ROC_WIDTH
It was like this in the timesim.vhd:
X_ROC
generic map (ROC_WIDTH => 100 ns)
port map (O => GSR);
Actual delay of the element is 4 ns.
Article: 100282I registered a 37-bit signal using an always block in verilog without reset specification, hoping that a SRL would be inferred if registering is done without a reset. But ISE still implemented it as a 37-bit register using flops. Could anyone please let me know if I missed out something? Any comments/suggestions would be appreciated. Thanks in advance.Article: 100283
Hi Subhasri, are the fifo write data generated internally or are they external data ? Rgds Andr=E9Article: 100284
"David Colson" <dscolson@rcn.com> writes: > Actually the new ieee1532 bsdl file does describe the programming > algorithm. Now I understand why you used the term "decipher". Personally I find it more straight forward to use SVF. 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: 100285
On a sunny day (Wed, 05 Apr 2006 17:47:09 -0700) it happened John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in <a0p832tsdsap1ivpo4ok0fqearc8s6iad1@4ax.com>: >On 5 Apr 2006 14:00:24 -0700, panteltje@yahoo.com wrote: > >> >>John Larkin schreef: >> >> >>> And if I had the Verilog, the first thing I'd do is grab a piece of >>> paper and sketch it out to understand what it does. >>> >>> Some people think verbally, some visually. >>> >>> John >>OK, so say I wanted a low pass, and wrote: >> >>/* 12.5 MHz clock chroma lowpass */ >>`define F0 0 >>`define F1 -2 >>`define F2 2 >>`define F3 8 >>`define F4 -3 >>`define F5 -21 >>`define F6 5 >>`define F7 80 >>`define F8 127 >>`define F9 80 >>`define F10 5 >>`define F11 -21 >>`define F12 -3 >>`define F13 8 >>`define F14 2 >>`define F15 -2 >>`define F16 0 >> >> >>module fir( clock, fir_in, fir_out); >>wire clock; >>input fir_in; >>output fir_out; >> >>wire [7:0] fir_in; >>reg [7:0] fir_out; >>reg [31:0] temp; >> >>reg [7:0] sm0; >>reg [7:0] sm1; >>reg [7:0] sm2; >>reg [7:0] sm3; >>reg [7:0] sm4; >>reg [7:0] sm5; >>reg [7:0] sm6; >>reg [7:0] sm7; >>reg [7:0] sm8; >>reg [7:0] sm9; >>reg [7:0] sm10; >>reg [7:0] sm11; >>reg [7:0] sm12; >>reg [7:0] sm13; >>reg [7:0] sm14; >>reg [7:0] sm15; >>reg [7:0] sm16; >> >> >>always @(posedge clock) >>begin >> sm16 = sm15; >> sm15 = sm14; >> sm14 = sm13; >> sm13 = sm12; >> sm12 = sm11; >> sm11 = sm10; >> sm10 = sm9; >> sm9 = sm8; >> sm8 = sm7; >> sm7 = sm6; >> sm6 = sm5; >> sm5 = sm4; >> sm4 = sm3; >> sm3 = sm2; >> sm2 = sm1; >> sm1 = sm0; >> sm0 = fir_in; >> >>temp = >> (`F0 * sm0) + (`F1 * sm1) + (`F2 * sm2) + (`F3 * sm3) + >> (`F4 * sm4) + (`F5 * sm5) + (`F6 * sm6) + (`F7 * sm7) + >> (`F8 * sm8) + (`F9 * sm9) + (`F10 * sm10) + (`F11 * sm11) + >> (`F12 * sm12) + (`F13 * sm13) + (`F14 * sm14) + (`F15 * sm15) + (`F16 >>* sm16); >> >>fir_out = temp / 512; >>end >> >>---------- >>How would you draw that? >> > >The same way people drew FIR filters before HDLs were invented. It's >very simple and very intuitive... looks just like an analog >transversal filter. > >John Sure, possible. But this IS a lot faster, and more readable in my view. Actually I tried it that way (you describe), and even to get a 64 order you will need a BIG piece of paper..... make it 32 wide... But nobody is stopping you.Article: 100286
Hi Rohit,
"Rohit Tandon" <rohit2000s@gmail.com> wrote in message
news:1144314403.793406.220210@e56g2000cwe.googlegroups.com...
> I registered a 37-bit signal using an always block in verilog without
> reset specification, hoping that a SRL would be inferred if registering
> is done without a reset. But ISE still implemented it as a 37-bit
> register using flops. Could anyone please let me know if I missed out
> something? Any comments/suggestions would be appreciated. Thanks in
> advance.
The conditions for SRL16 inference for are:
(1) No resets (which you've covered);
(2) Identical clock-enables for all registers, or no clock-enables;
(3) Output of stage N feeds input of stage N+1 with no intervening logic;
(4) Output of each stage does not feed any other destination
For example, if you want a parallel-in, serial-out shift register (or
serial-in, parallel-out) then you cannot use SRL16s. Make sure all the
conditions above are met by your circuit.
Also check that SRL16 inference is enabled in your synthesis tool's options
(in your case XST, I guess).
If it still doesn't work, perhaps you could post the code for us to look at?
Cheers,
-Ben-
Article: 100287hello folks, i'm working with a avnet board that has a xc2v1500 and i've been trying to use the ddr memory it has. i can't get it to work, when i start the placement, edk complains that the placement constraints, that is the ddr pin assignment, are causing an IOB conflict. i've tried to use floorplanner to solve the conflicts but it didn't help. i'll send the error output and if someone knows of something i can do, or have had the same problem and can help me out i would be glad. Phase 12.24 ERROR:Place:17 - The placement constraints of the IOBs fpga_0_Generic_DDR_DDR_DM_pin<0> and fpga_0_Generic_DDR_DDR_DQS_pin<0> makes this design unroutable due to a physical routing limitation. This device has a shared routing resource connecting the ICLK and OTCLK pins on pairs of IOBs. This restriction means that these pairs of pins must be driven by the same signal or one of the signals will be unroutable. Before continuing please remove the placement constraints or move one of these IOBs to a new location. ERROR:Place:17 - The placement constraints of the IOBs fpga_0_Generic_DDR_DDR_CKE_pin and fpga_0_Generic_DDR_DDR_DQS_pin<1> makes this design unroutable due to a physical routing limitation. This device has a shared routing resource connecting the ICLK and OTCLK pins on pairs of IOBs. This restriction means that these pairs of pins must be driven by the same signal or one of the signals will be unroutable. Before continuing please remove the placement constraints or move one of these IOBs to a new location. Phase 12.24 (Checksum:7270df4) REAL time: 1 mins 9 secs NOTE: the placement constraints are the ones supplied by the board manufacturer. thank's for any help.Article: 100288
Rohit Tandon wrote:
> I registered a 37-bit signal using an always block in verilog without
> reset specification, hoping that a SRL would be inferred if registering
> is done without a reset. But ISE still implemented it as a 37-bit
> register using flops. Could anyone please let me know if I missed out
> something? Any comments/suggestions would be appreciated. Thanks in
> advance.
Howdy Rohit,
SRL inferrance usually works, so to actually be of much help, we need
to know:
1. What synthesis program you're using (XST? Synplify?)
2. What code you are using for the SRL inferrance (copy and paste a
simplified always block that you are trying to use)
Good luck,
Marc
Article: 100289
Jim Granville wrote:
> John_H wrote:
>> > I could use "a Bourns network" or the like. I anticipate using 0603s
> > because they're small, available, routable. Unless there's experience
> > that says these tiny discretes should, indeed, be a resistor network
> > instead.
> >
> > I could use the quad-smd's. Is there a reason I should? Shouldn't?
> >
> > I'm hoping more for tidbits of experience rather than good ideas.
>
> Mainly it's a packing density issue. IIRC the pitch on the
> Quads, matches that of common TQFP packages.
> They are also on the right part of the price curve, and
> slash the resistor placement bill by 3/4.
When I'm doing a very dense board design, I typically use 0402
resistors because they can be tucked almost anywhere at will. IE, you
aren't contrained to finding place(s) to set down one or more quad
packs. Said another way, on average, I think I get better placement on
densely routed boards using single 0402's. If you lower the density
though, it probably makes sense to go to packs assuming your
manufacturing house can make the boards without solder shorts on the
packs.
Have fun,
Marc
Article: 100290Talking with the local apps. eng. it sounds like the speeds may be more in the 2-300MHz range. Time to do some reading....Article: 100291
"Andy Peters" <Bassman59a@yahoo.com> wrote in message news:1144276764.165125.290340@z34g2000cwc.googlegroups.com... > Anonymous wrote: > > Dumb question: Since USB is just a two wire serial interface and all the USB > > solutions I've seen are simple, though speedy, microcontrollers why can't > > the USB be inside the fpga? Seems like you can instantiate a small micro > > running at 50 mhz or so with code in a couple block rams to do what the fx2, > > for example, does. Apparently, doesn't exist so there must be some reason? > > It's a little more complex than simply two wires between two devices. > > USB signalling is half-duplex differential, and high-speed signalling > is different than full-speed and low-speed. Also, there are some > instances where single-ended signalling is used and the driver must be > capable of doing this and the receiver has to be able to detect these > states. > > -a > I agree the software is complicated. (Way too complicated in my opinion.) But all the solutions out there seem to be built around a little 8-bit micro. You don't think it's silly to have a 10 million gate FPGA sitting next to an 8051? There must be a real reason for it. Maybe I'll try it when I get some time. -ClarkArticle: 100292
I'm using Verilog with the Altera Cyclone II / Nios II) development kit. I'm not yet very experienced with FPGAs. My present design creates text to be superimposed on a TV picture or on a raster created by the FPGA. At this stage of the design, I read character codes and shapes from the dev kit flash memory (which was initialised by another application). There are no input signals except that I use one of the dev kit push-buttons to select an NTSC or PAL raster. That signal is registered to minimise problems with metastability. There are two output signals: composite sync and two-level (black/white) video, which I combine in a resistor network and feed to a TV monitor. In development, I had bizarre behaviour where a minor change to one part of the design changed the behaviour of completely unconnected parts. Simulation did not show these changes. The result was corrupted text (incorrect characters selected and/or corrupted shapes). Another symptom was that one or more of the dev kit LEDs would light and in one case the brightness depended on the state of the push-button. My design does not drive the LEDs and I have configured Quartus to set unused pins as "tri-state with weak pull-up". (On this development kit, the LEDs are driven by a low output). At first, I assumed it must be my fault, but I checked that my design is fully synchronous. Quartus reports that it should work up to about 150MHz and I'm using only the on-board 50MHz clock. The only aspect of the design unknown to Quartus was the behaviour of the external flash memory (which I read, but do not write). But the flash address is registered to prevent glitches and I don't clock the data until about twice the access time has elapsed. The corruption on-screen is quite repeatable. I ran my fingers along the pins of the flash device to see if the altered timing made any change to the display. It does not. The results were completely confusing so (since the final design will not use flash memory) I gave up after a couple of days. I removed all my diagnostic signals and the design started to work perfectly !! I've seen a similar problem today and I now suspect that it is caused when there are output signals at the top level of the design which are not assigned to pins. (This is an easy way to make them appear in the simulation report). As I start assigning the diagnostic top-level signals to unused pins, the problems go away. Am I missing something here? Am I making a fundamental mistake or is there a Quartus option "Connect Unassigned Top-level Signals to Random Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals into some Lower-level Module" ? MikeArticle: 100293
Ben Jones wrote:
> Hi Rohit,
>
> "Rohit Tandon" <rohit2000s@gmail.com> wrote in message
> news:1144314403.793406.220210@e56g2000cwe.googlegroups.com...
> > I registered a 37-bit signal using an always block in verilog without
> > reset specification, hoping that a SRL would be inferred if registering
> > is done without a reset. But ISE still implemented it as a 37-bit
> > register using flops. Could anyone please let me know if I missed out
> > something? Any comments/suggestions would be appreciated. Thanks in
> > advance.
>
> The conditions for SRL16 inference for are:
>
> (1) No resets (which you've covered);
> (2) Identical clock-enables for all registers, or no clock-enables;
> (3) Output of stage N feeds input of stage N+1 with no intervening logic;
> (4) Output of each stage does not feed any other destination
>
> For example, if you want a parallel-in, serial-out shift register (or
> serial-in, parallel-out) then you cannot use SRL16s. Make sure all the
> conditions above are met by your circuit.
>
> Also check that SRL16 inference is enabled in your synthesis tool's options
> (in your case XST, I guess).
>
> If it still doesn't work, perhaps you could post the code for us to look at?
>
> Cheers,
>
> -Ben-
Thanks to both of you for your quick replies. Actually I was using
output of one stage of the shift register in the logic elsewhere in the
design, when I modified it, XST was infering a SRL (without the need
for XST SRL tool option).
I was wondering if a similar solution can be applied to another problem
where I need to just add some 2-cycles of delay to a 4-bit register.
For instance if I have something like this:
reg [3:0] reg_in ;
reg [3:0] reg_out ;
reg [3:0] reg_r1 ;
always @ (posedge clk)
begin
{reg_out, reg_r1} <= {reg_r1, reg_in} ;
end
Can this logic be modified to make use of SRLs or do I need to
invariably implement it via flops.
Thanks in advance
-Rohit
Article: 100294
MikeShepherd564@btinternet.com wrote:
> Am I missing something here? Am I making a fundamental mistake or is
> there a Quartus option "Connect Unassigned Top-level Signals to Random
> Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals
> into some Lower-level Module" ?
Quartus does reserve the right to drive "unused"
pins with random internal nodes, which I find
a baffling default.
However I have never seen this happen when
unused pins are assigned to tristate.
I would open case with Altera.
-- Mike Treseler
Article: 100295Any port in the tio-level-design will become a pin, regardless if it is assigned to a location or not. If no location is specified, Quartus will choose one for you. I think this behavior cannot be changed (maybe you could try "virtual" pins). Thomas www.entner-electronics.com <MikeShepherd564@btinternet.com> schrieb im Newsbeitrag news:6o2a32dsbr4vlt9bar7vh7lek3j0v3qfn0@4ax.com... > I'm using Verilog with the Altera Cyclone II / Nios II) development > kit. I'm not yet very experienced with FPGAs. My present design > creates text to be superimposed on a TV picture or on a raster created > by the FPGA. > > At this stage of the design, I read character codes and shapes from > the dev kit flash memory (which was initialised by another > application). There are no input signals except that I use one of the > dev kit push-buttons to select an NTSC or PAL raster. That signal is > registered to minimise problems with metastability. > > There are two output signals: composite sync and two-level > (black/white) video, which I combine in a resistor network and feed to > a TV monitor. > > In development, I had bizarre behaviour where a minor change to one > part of the design changed the behaviour of completely unconnected > parts. Simulation did not show these changes. The result was > corrupted text (incorrect characters selected and/or corrupted > shapes). Another symptom was that one or more of the dev kit LEDs > would light and in one case the brightness depended on the state of > the push-button. My design does not drive the LEDs and I have > configured Quartus to set unused pins as "tri-state with weak > pull-up". (On this development kit, the LEDs are driven by a low > output). > > At first, I assumed it must be my fault, but I checked that my design > is fully synchronous. Quartus reports that it should work up to about > 150MHz and I'm using only the on-board 50MHz clock. The only aspect > of the design unknown to Quartus was the behaviour of the external > flash memory (which I read, but do not write). But the flash address > is registered to prevent glitches and I don't clock the data until > about twice the access time has elapsed. > > The corruption on-screen is quite repeatable. I ran my fingers along > the pins of the flash device to see if the altered timing made any > change to the display. It does not. > > The results were completely confusing so (since the final design will > not use flash memory) I gave up after a couple of days. I removed all > my diagnostic signals and the design started to work perfectly !! > > I've seen a similar problem today and I now suspect that it is caused > when there are output signals at the top level of the design which are > not assigned to pins. (This is an easy way to make them appear in the > simulation report). As I start assigning the diagnostic top-level > signals to unused pins, the problems go away. > > Am I missing something here? Am I making a fundamental mistake or is > there a Quartus option "Connect Unassigned Top-level Signals to Random > Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals > into some Lower-level Module" ? > > MikeArticle: 100296
Hi,
The fifo write data is generated internally.
module FifoTest(clk, data_out, d_in);
input clk;
output [7:0] data_out;
output [7:0] d_in;
wire wr_en;
wire rd_en;
wire [7:0] d_in;
wire [7:0] data_out;
reg rd_en_reg;
reg [7:0] data_in_reg;
//Wires tied to values
wire reset =3D 1'b0;
assign wr_en =3D (reset) ? 1'b0 : 1'b1;
assign rd_en =3D rd_en_reg;
// The following must be inserted into your Verilog file for this
// core to be instantiated. Change the instance name and port
connections
// (in parentheses) to your own signal names.
fifo_8bit_32deep Sync_Fifo (
.clk(clk),
.sinit(reset),
.din(d_in),
.wr_en(wr_en),
.rd_en(rd_en),
.dout(data_out)
);
//Generate Data
assign d_in =3D data_in_reg;
always @ (posedge clk)
if(reset)
data_in_reg <=3D 0;
else
data_in_reg <=3D data_in_reg + 1;
//Read Enable is Delayed Write Enable
reg rd_en_reg_dly1, rd_en_reg_dly2;
always @ (posedge clk)
if(reset)
begin
rd_en_reg_dly1 <=3D 0;
rd_en_reg_dly2 <=3D 0;
rd_en_reg <=3D 0;
end
else
begin
rd_en_reg_dly1 <=3D wr_en;
rd_en_reg_dly2 <=3D rd_en_reg_dly1;
rd_en_reg <=3D rd_en_reg_dly2;
end
endmodule
The read enable is a delayed write enable. Please open the link in my
original post to see the testbench waveform and chipscope waveform. I
have highlighted and compared the two outputs. I would like to know why
there is a discrepancy. Thanks for replying.
- Subhasri.K
ALuPin@web.de wrote:
> Hi Subhasri,
>
> are the fifo write data generated internally or
> are they external data ?
>=20
> Rgds
> Andr=E9
Article: 100297
hi,
In my design on a Spartan-3 I use a number of block RAMs. In most of
them, I have a few ports unconnected, but in only one of them I get a
warning:
DesignRules:332 - Blockcheck: Dangling RAMB16B output. Pin DOPB0 of
comp ram is not connected.
The RAM is used across 2 clock domains, and is only read on port A, and
only written on port B. For this reason, inputs on port A are
unconnected, as well as outputs on port B.
here's the instantiation:
RAMB16_S9_S9 ram(
.WEA(1'b0),
.ENA(en_a),
.SSRA(init),
.CLKA(clock_a),
.ADDRA(addr_a),
.DOA(out_a[7:0]),
.DOPA(out_a[8]),
.WEB(we_b),
.ENB(we_b),
.SSRB(1'b0),
.CLKB(clock_b),
.ADDRB(addr_b),
.DIB(in_b[7:0]),
.DIPB(in_b[8])
);
The strange thing is that other block RAMs in the same design, that are
used in similar ways (although not identical), don't elicit any
warnings, even though the same output ports are unconnected.
I'm using XST, ISE Webpack 6.2
Everything works fine, but I'd like to get rid of the warning that's
cluttering up the output.
Article: 100298>Quartus does reserve the right to drive "unused" >pins with random internal nodes, which I find >a baffling default. > >However I have never seen this happen when >unused pins are assigned to tristate. >I would open case with Altera. > > -- Mike Treseler Thanks for that, Mike. I'll maybe raise it with them when I have more confidence that I know what I'm doing with Quartus. For now, at least I can just make sure not to have unused signals at the top level. MikeArticle: 100299
Jim, I do not think it is any different in this regard, but Steve will correct me if I am wrong, Austin Jim Granville wrote: > Austin Lesea wrote: > >> Jim, >> >> The tap state machine is always trying to keep one entire period in >> one of the delay lines. This way, the unit is always self >> calibrating, it always "knows" how many taps equals one period. >> >> So when you ask for 23/256 of a period shift, the arithmetic unit >> solves for the closet tap (truncating). >> >> To make the silicon take up less space, the delay line itself is >> optimized to not change over the PVT (as much as it would otherwise). >> >> How this is done is the subject of issued patents, so for those that >> are curious, they can look these up. > > > Yes, I can follow that for the -3, but Steve was suggesting the 3E was > slightly different, so I was wanting to clarify the deails. > > -jg > > > >>>>> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: >>>> >>>> The Spartan-3E DLL also performs a variable phase >>>> shift using a delay line. However, in Spartan-3E, you have raw control >>>> over the delay. The shift is always in time, not in some angular unit. > >
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