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 Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com" <colin_toogood@yahoo.com> wrote: >Guys > >I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power >plane. It is showing a 30mV voltage drop across the BGA itself, let >alone getting the power to the BGA which is dropping another 50mV. > >Surely the 30mV cannot be true as there is a power plane in the BGA >package itself. > >Historically I would look at the size of the plane and assume that >everything is fine and I can't help wondering whether this worst case >analysis is a bit pointless. > >Any opinions? > >BTW I'm already just beyond the PCB thickness I'm allowed so I can't >just use thicker copper. > >Colin > >PS. sorry about using Google, I'm sitting in the UK behind a firewall >controlled by an Indian call centre. How much current are you expecting in the core? What do mean by "30mV voltage drop across the BGA itself" ? Does that mean PCB plane drop, or rather BGA balls to chip internal voltage? The chip vendors should give us one remote-sense feedback/measurement ball. JohnArticle: 153201
On 06 Jan 2012 15:07:31 GMT, Allan Herriman <allanherriman@hotmail.com> wrote: >On Fri, 06 Jan 2012 13:53:05 +0000, Allan Herriman wrote: > >> On Fri, 06 Jan 2012 01:55:03 -0800, colin_toogood@yahoo.com wrote: >> >>> Guys >>> >>> I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power >>> plane. It is showing a 30mV voltage drop across the BGA itself, let >>> alone getting the power to the BGA which is dropping another 50mV. >>> >>> Surely the 30mV cannot be true as there is a power plane in the BGA >>> package itself. >>> >>> Historically I would look at the size of the plane and assume that >>> everything is fine and I can't help wondering whether this worst case >>> analysis is a bit pointless. >>> >>> Any opinions? >>> >>> BTW I'm already just beyond the PCB thickness I'm allowed so I can't >>> just use thicker copper. >> >> >> I've had this issue in recent designs too. Currents are higher, >> voltages are lower (1.0, 0.9V, etc), supply tolerances are tighter (3% >> instead of 5% now for some parts) but copper doesn't seem conduct any >> better :( >> >> About the only thing that's improving is the DC/DC converter; some parts >> have a reference precision better than 1% now. Transient response is >> also better due to faster switching frequencies and cheap, large, low >> ESR caps. >> >> >> The Cu in the BGA is thin. I don't know its sheet resistance, but it's >> probably greater than the (roughly) 1mohm / square of the inner layers >> of your PCB. At 20 or 30 amperes, you don't need many squares to get a >> voltage drop that puts you outside the supply voltage tolerance of the >> FPGA. >> >> In my last "high power" FPGA design, we ended up with a plane on an >> inner (1/2 oz) layer in parallel with a fill on an outer (1oz) layer for >> the core supply. The layout guy hated doing it, but it gave adequate >> results. >> >> It might also be possible to use smaller vias in your BGA fanout to >> reduce the "swiss cheese" effect on your planes, but I haven't tried >> that in an actual design. >> >> I've noticed that some PC motherboard manufacturers are advertising 2oz >> copper as a feature, so it's not just FPGA folk that are feeling the >> pain. > > >Another thing I've been doing is to boost the nominal voltage slightly. I do that, namely go 50 mV or so high out of my switchers, anticipating copper losses. I think the tight voltage specs on these FPGAs is part of the overall speed budget. If you're not pushing the clock rate/timing/temperature margins, it's not as critical. I also like to power-supply margin test working units, just to see how much wiggle room we have. Usually it's a lot. JohnArticle: 153202
On Fri, 06 Jan 2012 03:18:38 +0000, glen herrmannsfeldt wrote: > Philip Pemberton <philpem@philpem.me.uk> wrote: > >> I'm currently working on the HDL code for an open-source project which >> images 'strange and unusual' magnetic media (mainly floppy discs but >> also MFM and RLL hard disc drives). > >> To do this, I measure the time between incoming pulses on the RD_DATA >> line. One pulse indicates a magnetic transition. The time between a >> given pair of pulses encodes (in a roundabout way) a data bit. This is >> a gross oversimplification, but serves the purpose for this >> explanation. > >> After measuring the time between two pulses, it re-arms and measures >> between the second pulse and the one following it. Rinse, repeat. > >> The captured timing values are stored in an on-FPGA FIFO buffer, then >> passed onto an off-chip Cypress 100MHz 512K*8bit high speed static RAM >> (this thing needs A LOT of storage). The period counter's reference >> clock is 100MHz. 10 nanoseconds per count. The most significant bit is >> reserved for a 'flag' bit (it's used by other parts of the design), >> leaving a range of 0 to 127 for the counter. > > The bit rate for floppies is 125000b/s at the low end, and, as far as I > know, 1000000b/s at the high end. To decode FM or MFM data, you don't > need a hugh amount of resolution. There are only two different times > between transitions, at least ideally. > > The GCR code used by older Apple formats has more different times, but > not all that many, and the bit rate is on the low side. > > To write a floppy from data, you need to consider precompensation, which > needs a little finer timing. Note that writing a floppy from your data > stream, you will also need to consider precompensation. > > Anyway, my suggestion is to use a slower clock. Then it should only > overflow at splice points, or other places where the data doesn't > matter. > >> The problem is, a lot of the timing values are about 800 counts long. >> To work around this, I implemented logic to store a 'special' value in >> the stream if the counter overflows from 127 to 0. This value is "8'd0" >> -- 8 bits, all zeroes. > > The design of codes that can be uniquely decoded is well known. One > answer is to store one more than the overflow value. That is, a 128 > count should be X'0001', so X'00' always means overflow, and never data. > X'007f' then will be 254, and X'000001' will be 255. > > The logic is a little more complicated, but shouldn't be hard to fit > into an FPGA. > > -- glen If you want the data to fit neatly into seven bits, give your counter a period of 127, and assign X'00' to overflow, with X'01' through X'7f' denoting a bit hit at that count. That'll insure unique data, without blowing out your bit-count budget. You'll complicate the decoding a bit, but that's an easy task for a computer to carry out. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 153203
On Jan 6, 6:53=A0am, Allan Herriman <allanherri...@hotmail.com> wrote: > On Fri, 06 Jan 2012 01:55:03 -0800, colin_toog...@yahoo.com wrote: > > Guys > > > I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power > > plane. It is showing a 30mV voltage drop across the BGA itself, let > > alone getting the power to the BGA which is dropping another 50mV. > > > Surely the 30mV cannot be true as there is a power plane in the BGA > > package itself. > > > Historically I would look at the size of the plane and assume that > > everything is fine and I can't help wondering whether this worst case > > analysis is a bit pointless. > > > Any opinions? > > > BTW I'm already just beyond the PCB thickness I'm allowed so I can't > > just use thicker copper. > > I've had this issue in recent designs too. =A0Currents are higher, voltag= es > are lower (1.0, 0.9V, etc), supply tolerances are tighter (3% instead of > 5% now for some parts) but copper doesn't seem conduct any better :( > > About the only thing that's improving is the DC/DC converter; some parts > have a reference precision better than 1% now. =A0Transient response is > also better due to faster switching frequencies and cheap, large, low ESR > caps. > > The Cu in the BGA is thin. =A0I don't know its sheet resistance, but it's > probably greater than the (roughly) 1mohm / square of the inner layers of > your PCB. =A0At 20 or 30 amperes, you don't need many squares to get a > voltage drop that puts you outside the supply voltage tolerance of the > FPGA. > > In my last "high power" FPGA design, we ended up with a plane on an inner > (1/2 oz) layer in parallel with a fill on an outer (1oz) layer for the > core supply. =A0The layout guy hated doing it, but it gave adequate resul= ts. > > It might also be possible to use smaller vias in your BGA fanout to > reduce the "swiss cheese" effect on your planes, but I haven't tried that > in an actual design. > > I've noticed that some PC motherboard manufacturers are advertising 2oz > copper as a feature, so it's not just FPGA folk that are feeling the pain= . > > Regards, > Allan If you have an old version .dxf file [with scale] of your PCB plane and identify current magnitudes and injection points, tell me the two cutout diameters to test; I could compare the effect of the 'swiss cheese' on the voltage drop across the plane. Actually do 3D voltage plots showing NO HOLES, Small Holes, Large Holes, and Delta Voltage comparisons. I created a PCB Layout Tool that quantifies the Ground Plane Noise distributed across a PCB caused by currents from digital logic. Provide an email address that accepts .zip and I can send small example images of results in .zip attachment. approx 72kB [The purpose for creating the tool was to confirm parts placement and efficacy of plane cuts to keep GND noise below 1/4 LSB of the 24 bit ADC on the same PCB as the microcontroller. I simply got tired of 'shooting from the hip', worrying if the cut(s) is enough, and answering questions with, "In my opinion,..." Plus, wanted this PCB layout 'right' the first time.]Article: 153204
On Fri, 06 Jan 2012 12:18:50 -0600, Tim Wescott wrote:
> If you want the data to fit neatly into seven bits, give your counter a
> period of 127, and assign X'00' to overflow, with X'01' through X'7f'
> denoting a bit hit at that count. That'll insure unique data, without
> blowing out your bit-count budget.
>
> You'll complicate the decoding a bit, but that's an easy task for a
> computer to carry out.
That's more or less what I'm doing now.
The problem is, there's a race condition -- if there's an overflow at the
same time as an incoming data pulse, then the overflow is stored, but the
transition is ignored. In the example you gave, that's when the count is
*exactly* 127, or a modulo thereof.
What I need to do is eliminate this race condition...
Here's my code --
module DiscReader(CLOCK, CLKEN, RUN, FD_RDDATA_IN, FD_INDEX_IN, RESET,
DATA, WRITE);
parameter BITS = 8; // data bits
input
CLOCK; // counter clock
input
CLKEN; // counter clock enable
input
RUN; // enable input -- 1 to acquire
input FD_RDDATA_IN; //
read data
input FD_INDEX_IN; //
index pulse
input
RESET; // asynchronous reset
output reg [BITS-1:0] DATA; //
data output to RAM
output reg
WRITE; // write output to RAM
/////////////////////////////////////////////////////////////////////////////
// Input synchronisation
wire FD_RDDATA_IN_tcysync, FD_INDEX_IN_tcysync;
Flag_Delay1tcy_OneCycle _fcd_rddata (CLOCK, FD_RDDATA_IN,
FD_RDDATA_IN_tcysync);
Flag_Delay1tcy_OneCycle _fcd_index (CLOCK, FD_INDEX_IN,
FD_INDEX_IN_tcysync);
/////////////////////////////////////////////////////////////////////////////
// Free-running counter for frequency measurement
reg [BITS-2:0] counter, last_count;
always @(posedge CLOCK) begin
if (RESET) begin
// reset active -- clear counter
counter <= 'd0;
end else if (CLKEN) begin
// otherwise increment
counter <= counter + 'd1;
end
end
/////////////////////////////////////////////////////////////////////////////
// Frequency counter
// current counter value
wire [BITS-2:0] cur_count = (last_count <= counter) ?
counter - last_count : //
last count <= counter
('b1 << BITS) - last_count + counter; // last count >
counter
always @(posedge CLOCK) begin
// don't write to memory!
WRITE <= 1'b0;
if (RESET) begin
// reset active -- clear last-count
last_count <= 'd0;
end else begin
if (FD_RDDATA_IN_tcysync | FD_INDEX_IN_tcysync |
(cur_count == (('d1 << BITS-1)-1))) begin
// Index hit, flux transition or overflow
DATA <= {FD_INDEX_IN_tcysync ? 1'b1 :
1'b0, cur_count};
// write to memory
WRITE <= 1'b1;
// Update 'previous count value' register
last_count <= counter;
end
end
end
endmodule
module Flag_Delay1tcy_OneCycle(clk, in, out);
input clk, in;
output out;
reg[1:0] in_Delayed;
always @(posedge clk) in_Delayed <= {in_Delayed[0], in};
assign out = (in_Delayed[0] && !in_Delayed[1]);
endmodule
// Testbench -- provokes race condition in DiscReader module
// 5ns time reference with 1ns precision
`timescale 1 ns / 1 ns
module DiscReaderTB;
reg clock, run, rddata, index, reset;
wire clock_enable = 1'b1;
parameter N = 8;
wire [N-1:0] data_r;
wire ram_write;
// instantiate the disc reader
DiscReader U0 (
.CLOCK (clock),
.CLKEN (clock_enable),
.RUN (run),
.FD_RDDATA_IN (rddata),
.FD_INDEX_IN (index),
.RESET (reset),
.DATA (data_r),
.WRITE (ram_write)
);
// set initial state
initial begin
clock = 0;
run = 0;
rddata = 0;
index = 0;
reset = 0;
end
// generate a 100MHz clock
always
#1 clock = !clock;
// set up for variable dumping
initial begin
$dumpfile ("counter.vcd");
$dumpvars;
end
integer k;
// main loop
initial begin
#10
reset = 1;
#10
reset = 0;
run = 1;
for (k=0; k<=16; k=k+1) begin
rddata = 1;
#2
rddata = 0;
#252
;
end
#1000 $finish;
end
endmodule
Thanks.
--
Phil.
philpem@philpem.me.uk
http://www.philpem.me.uk/
Article: 153205Tim Wescott <tim@seemywebsite.com> wrote: (snip) >>> The problem is, a lot of the timing values are about 800 counts long. >>> To work around this, I implemented logic to store a 'special' value in >>> the stream if the counter overflows from 127 to 0. This value is "8'd0" >>> -- 8 bits, all zeroes. >> The design of codes that can be uniquely decoded is well known. One >> answer is to store one more than the overflow value. That is, a 128 >> count should be X'0001', so X'00' always means overflow, and never data. >> X'007f' then will be 254, and X'000001' will be 255. >> The logic is a little more complicated, but shouldn't be hard to fit >> into an FPGA. > If you want the data to fit neatly into seven bits, give your counter a > period of 127, and assign X'00' to overflow, with X'01' through X'7f' > denoting a bit hit at that count. That'll insure unique data, without > blowing out your bit-count budget. That is what I was thinking, but probably didn't get quite right. > You'll complicate the decoding a bit, but that's an easy task for a > computer to carry out. Well, easy for a computer, slightly harder to write as a state machine in verilog, but not that much harder. -- glenArticle: 153206
Philip Pemberton <philpem@philpem.me.uk> wrote: > On Fri, 06 Jan 2012 12:18:50 -0600, Tim Wescott wrote: >> If you want the data to fit neatly into seven bits, give your counter a >> period of 127, and assign X'00' to overflow, with X'01' through X'7f' >> denoting a bit hit at that count. That'll insure unique data, without >> blowing out your bit-count budget. >> You'll complicate the decoding a bit, but that's an easy task for a >> computer to carry out. > That's more or less what I'm doing now. > The problem is, there's a race condition -- if there's an overflow at the > same time as an incoming data pulse, then the overflow is stored, but the > transition is ignored. In the example you gave, that's when the count is > *exactly* 127, or a modulo thereof. > What I need to do is eliminate this race condition... No, it is worse than a race condition, you have one state that has two meanings. OK, the easy way is to do it modulo 64, and use the 64 value to mean 64, and 0 to mean 0. (It is easier to write modulo 64 than 127.) For 5.25in FM, the data rate is 125000b/s, the transitions are either at 8us or 4us, so there will be a lot of 80s. Not so good. For 5.25in MFM, the data rate is 250000b/s, there is no clock pulse if either the cell before or after has a data pulse. I believe that means either 4us or 6us, except for an address mark where it would be 8us. (I haven't thought about this for a while. Find a reference to the IBM standard.) OK, do it modulo 127 with 127 as the overflow code which allows for a zero code to mean zero. (Most likely only after a 127.) It isn't that hard to test for 127, and you have plenty of time to do it. -- glenArticle: 153207
On 4 Jan., 19:52, chthon <jurgen.defu...@gmail.com> wrote: > Hello, > > I am trying to decide what board to order for a project I want to do betw= een April and June in school, > I have currently staked out the following boards, based upon the features= I need and the price. > > Digilent =A0 | Atlys =A0 =A0 =A0 =A0 =A0| > Xilinx | 3A Starter kit | > However, also delivery time and ease of ordering are somewhat necessary, = and three of the five boards come from the US, while 2 come from the UK, an= d I live in Belgium. Atlys boards are in stock at trenz electronic in Germany: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=3D1_114_119&= products_id=3D829&language=3Den and so is the 3A starter kit: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=3D1_47&produ= cts_id=3D130&language=3Den Regards, KoljaArticle: 153208
On 01/05/2012 10:18 PM, glen herrmannsfeldt wrote: > The bit rate for floppies is 125000b/s at the low end, and, as far as > I know, 1000000b/s at the high end. To decode FM or MFM data, you > don't need a hugh amount of resolution. There are only two different > times between transitions, at least ideally. > > The GCR code used by older Apple formats has more different times, but > not all that many, and the bit rate is on the low side. > > To write a floppy from data, you need to consider precompensation, > which needs a little finer timing. Note that writing a floppy from > your data stream, you will also need to consider precompensation. > > Anyway, my suggestion is to use a slower clock. Then it should only > overflow at splice points, or other places where the data doesn't > matter. What Philip failed to mention was that the product in question is also intended to read data streams from MFM hard drives. A slower clock may not be an option.Article: 153209
Steven Hirsch <snhirsch@gmail.com> wrote: (snip, I wrote) >> To write a floppy from data, you need to consider precompensation, >> which needs a little finer timing. Note that writing a floppy from >> your data stream, you will also need to consider precompensation. >> Anyway, my suggestion is to use a slower clock. Then it should only >> overflow at splice points, or other places where the data doesn't >> matter. > What Philip failed to mention was that the product in question is also > intended to read data streams from MFM hard drives. A slower clock may not be > an option. I was assuming that you knew which type of drive you were working with and could select accordingly. Interestingly, though, the IBM PC/AT disk controller uses a 24MHz crystal for the floppy drive, and, if I remember right, 10MHz for the MFM hard drive. -- glenArticle: 153210
On Fri, 06 Jan 2012 20:49:01 +0000, Philip Pemberton wrote:
> On Fri, 06 Jan 2012 12:18:50 -0600, Tim Wescott wrote:
>
>> If you want the data to fit neatly into seven bits, give your counter a
>> period of 127, and assign X'00' to overflow, with X'01' through X'7f'
>> denoting a bit hit at that count. That'll insure unique data, without
>> blowing out your bit-count budget.
>>
>> You'll complicate the decoding a bit, but that's an easy task for a
>> computer to carry out.
>
> That's more or less what I'm doing now.
>
> The problem is, there's a race condition -- if there's an overflow at
> the same time as an incoming data pulse, then the overflow is stored,
> but the transition is ignored. In the example you gave, that's when the
> count is *exactly* 127, or a modulo thereof.
>
> What I need to do is eliminate this race condition...
>
(lots of headache-inducing code snipped)
It shouldn't. A number between 1 and 127 means that you got an event at
that time. A zero means that your counter went from 127 to _1_ (because
0 is forbidden).
// Note that my Verilog is very rusty: hopefully you'll get the idea
// This should cause a count between 1 and 127 to be emitted when an
// event occurs, and a 'count' of 0 to be emitted _only_ when an
// overflow occurs.
if (event)
begin
out <= count;
emit <= 1;
end
else if (count == 127)
begin
out <= 0;
emit <= 1;
end
// The counter update is independent to the above:
if (count == 127)
count <= 1;
else
count <= count + 1;
Like Glen said, the above is somewhat logic-intensive because you're
counting modulo 127 -- but it can be done.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Article: 153211Colin I'm not surprised at the numbers you are quoting. Personnally I would be more worried by the dynamic current variation and the effects that that the resistance and the parasitic inductance can have. If your decoupling isn't good enough ,and your power plane forms part of that, the effect of getting it wrong is far harder to debug than a static voltage issue. Going back to the static losses using parallel planes is a good option as mentioned elsewhere. You can also go for heavier weights of copperin your power planes but that tends to restrict you track and gap you can use. This also related to the abilities of the manufacturer of your PCB and sometimes the price you pay for a PCB. There are also speciality PCB techniques like bonding busbars to the PCB to reduce the resistive loss but usually it's better to use a point of load technique and localise the high current areas. You can see examples of that technique in our extrene Merrick family of boards which are aimed at the HPC marketplace. Our recently annouced Merrick3 http://enterpoint.co.uk/products/asic-development-high-performance-computin= g/merrick-3/ uses 6 12A circuits just in PCIe card format for the core voltage. Internal distribution is by 12V rail in this case. Our new revision of our Merrick1 board will take this further and there are 20 POL regulators just for the core voltage. One easy thing to do is to set you power supply on the higher end of the input specification at light load. Tolerance of your power supply is important if you use this method. Then even after losses hopefully your FPGA die is still receiving voltage within spec. Many FPGAs will still operate out of spec although may not meet timing spec. Sometimes this can be used to solve a particular power issue but use with care. John Adair Enterpoint Ltd. - Home of FPGA HPC solutions. On Jan 6, 9:55=A0am, "colin_toog...@yahoo.com" <colin_toog...@yahoo.com> wrote: > Guys > > I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power > plane. It is showing a 30mV voltage drop across the BGA itself, let > alone getting the power to the BGA which is dropping another 50mV. > > Surely the 30mV cannot be true as there is a power plane in the BGA > package itself. > > Historically I would look at the size of the plane and assume that > everything is fine and I can't help wondering whether this worst case > analysis is a bit pointless. > > Any opinions? > > BTW I'm already just beyond the PCB thickness I'm allowed so I can't > just use thicker copper. > > Colin > > PS. sorry about using Google, I'm sitting in the UK behind a firewall > controlled by an Indian call centre.Article: 153212
On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com" ><colin_toogood@yahoo.com> wrote: > >>Guys >> >>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power >>plane. It is showing a 30mV voltage drop across the BGA itself, let >>alone getting the power to the BGA which is dropping another 50mV. >> >>Surely the 30mV cannot be true as there is a power plane in the BGA >>package itself. >> >>Historically I would look at the size of the plane and assume that >>everything is fine and I can't help wondering whether this worst case >>analysis is a bit pointless. >> >>Any opinions? >> >>BTW I'm already just beyond the PCB thickness I'm allowed so I can't >>just use thicker copper. >> >>Colin >> >>PS. sorry about using Google, I'm sitting in the UK behind a firewall >>controlled by an Indian call centre. > >How much current are you expecting in the core? > >What do mean by "30mV voltage drop across the BGA itself" ? Does that >mean PCB plane drop, or rather BGA balls to chip internal voltage? > >The chip vendors should give us one remote-sense feedback/measurement >ball. > >John > You can probably already take your pick.....if you sacrifice the immediate local signal functions. RLArticle: 153213
Jurgen Have you seen our ADV7202 module http://www.enterpoint.co.uk/moelbryn/modul= es/adv7202.html? and does that cover what you want to do? We also have a HDMI solution on the way that might of interest to some people. John Adair Enterpoint Ltd. On Jan 4, 6:52=A0pm, chthon <jurgen.defu...@gmail.com> wrote: > Hello, > > I am trying to decide what board to order for a project I want to do betw= een April and June in school, and for other projects, mainly to exercise VH= DL and design interesting projects. The school project itself is the design= of a general purpose DSP data path. > > I have currently staked out the following boards, based upon the features= I need and the price. > > Digilent =A0 | Atlys =A0 =A0 =A0 =A0 =A0| > Enterpoint | Drigmorn-3 =A0 =A0 | > Xilinx =A0 =A0 | 3A Starter kit | > Enterpoint | Drigmorn-2 =A0 =A0 | > Xilinx =A0 =A0 | 3E Starter kit | > > However, also delivery time and ease of ordering are somewhat necessary, = and three of the five boards come from the US, while 2 come from the UK, an= d I live in Belgium. > > On the other hand, the Drigmorn boards do not feature a video output (wha= tever type), which is also something I would like to have. > > And then there is the choice of FPGA: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LX16 =A0 XC3S700A > Logic cells: =A0 =A0 14579 =A013248 > Slices =A0 =A0 : =A0 =A0 2278 =A0 5888 > Block RAM =A0: =A0 =A0 576 =A0 =A0360 > Distributed RAM: 136 =A0 =A092 > > Since a LX16 seems to have less slices than a XC3S700A, does that mean th= at the LX16 will reach its maximum earlier than the XC3S700A? Conversely, d= oes the lesser amount of distributed RAM on the XC3S700A mean that it could= be that in a pipelined design it has less possibilities than the LX16? > > I must say, that if I have to select purely on price, this would certainl= y favor the Drigmorn-2, but does the choice of the XC3S700A FPGA in that ca= se limit me in my design choices? > > And another point, I only own a MacBook Air anymore, with Linux on Virtua= lbox and ISE inside it, but how does this translate in my choices for progr= amming the selected board? > > Regards, > > Jurgen DefurneArticle: 153214
On Sun, 08 Jan 2012 10:53:56 -0500, legg <legg@nospam.magma.ca> wrote: >On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >>On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com" >><colin_toogood@yahoo.com> wrote: >> >>>Guys >>> >>>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power >>>plane. It is showing a 30mV voltage drop across the BGA itself, let >>>alone getting the power to the BGA which is dropping another 50mV. >>> >>>Surely the 30mV cannot be true as there is a power plane in the BGA >>>package itself. >>> >>>Historically I would look at the size of the plane and assume that >>>everything is fine and I can't help wondering whether this worst case >>>analysis is a bit pointless. >>> >>>Any opinions? >>> >>>BTW I'm already just beyond the PCB thickness I'm allowed so I can't >>>just use thicker copper. >>> >>>Colin >>> >>>PS. sorry about using Google, I'm sitting in the UK behind a firewall >>>controlled by an Indian call centre. >> >>How much current are you expecting in the core? >> >>What do mean by "30mV voltage drop across the BGA itself" ? Does that >>mean PCB plane drop, or rather BGA balls to chip internal voltage? >> >>The chip vendors should give us one remote-sense feedback/measurement >>ball. >> >>John >> >You can probably already take your pick.....if you sacrifice the >immediate local signal functions. > >RL I can sense an I/O bank supply voltage by just pulling an output up, but core voltage is harder to get at. I could swipe one ball out of, say, ten paralleled ones, I guess, if I were sure they were really paralleled. Are core voltages segmented on most FPGAs, or are all the Vcc_core balls connected to one power net? JohnArticle: 153215
In comp.arch.fpga John Larkin <jjlarkin@highnotlandthistechnologypart.com> wrote: (snip, someone wrote) >>>What do mean by "30mV voltage drop across the BGA itself" ? Does that >>>mean PCB plane drop, or rather BGA balls to chip internal voltage? (snip) > I can sense an I/O bank supply voltage by just pulling an output up, > but core voltage is harder to get at. I could swipe one ball out of, > say, ten paralleled ones, I guess, if I were sure they were really > paralleled. As far as I know, you aren't supposed to do that. Even if they are paralleled internally, there might be enough voltage drop across the internal connection to cause problems. > Are core voltages segmented on most FPGAs, or are all the Vcc_core > balls connected to one power net? My choice would be to run a wire out from one of the power balls and measure the voltage on that wire. You could even use a power supply with a remote sense, such that it would adjust its output to get the right voltage on the sense line. Maybe even sense lines for both Vcc and ground. If you don't have remote sense on the power supply, just use them as a remote voltage measurment. -- glenArticle: 153216
On Sun, 08 Jan 2012 10:48:37 -0800, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Sun, 08 Jan 2012 10:53:56 -0500, legg <legg@nospam.magma.ca> wrote: > >>On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin >><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >> >>>On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toogood@yahoo.com" >>><colin_toogood@yahoo.com> wrote: >>> >>>>Guys >>>> >>>>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power >>>>plane. It is showing a 30mV voltage drop across the BGA itself, let >>>>alone getting the power to the BGA which is dropping another 50mV. >>>> >>>>Surely the 30mV cannot be true as there is a power plane in the BGA >>>>package itself. >>>> >>>>Historically I would look at the size of the plane and assume that >>>>everything is fine and I can't help wondering whether this worst case >>>>analysis is a bit pointless. >>>> >>>>Any opinions? >>>> >>>>BTW I'm already just beyond the PCB thickness I'm allowed so I can't >>>>just use thicker copper. >>>> >>>>Colin >>>> >>>>PS. sorry about using Google, I'm sitting in the UK behind a firewall >>>>controlled by an Indian call centre. >>> >>>How much current are you expecting in the core? >>> >>>What do mean by "30mV voltage drop across the BGA itself" ? Does that >>>mean PCB plane drop, or rather BGA balls to chip internal voltage? >>> >>>The chip vendors should give us one remote-sense feedback/measurement >>>ball. >>> >>>John >>> >>You can probably already take your pick.....if you sacrifice the >>immediate local signal functions. >> >>RL > >I can sense an I/O bank supply voltage by just pulling an output up, >but core voltage is harder to get at. I could swipe one ball out of, >say, ten paralleled ones, I guess, if I were sure they were really >paralleled. Probably not a good idea. You'll be leaving one corner of the power mesh sagging. A sense to the pad might not be a bad idea, though. ...if you can control the regulator. >Are core voltages segmented on most FPGAs, or are all the Vcc_core >balls connected to one power net? Paralleled.Article: 153217
I should have probably have clarified the POL approach for a single FPGA. Some of the regulators we use are capable of being used in tandem so you might use 2 or 4 of them together. They do need to be tied together to avoid issues caused by large differences. This does avoid all of the current being delivered in a small contact area which can reduce losses and is sort of similar to the approach taken by most FPGAs themselves. It's also worth pointing out that there are always differences between individual FPGA power balls but they are small and FPGAs do cope with that. Sometimes part of the effect is more current gets dragged through an individual "good" ball causing more volts drop and crudely self regulating. If we are looking at losses don't forget the vias. We recently did a 50A circuit on our Broaddown3 board and to keep losses reasonable we put something like 30 vias between the regulators arms and the internal plane. This is more extreme than most people will need to think about and you can argue about which size of via to use as there are some trades here in numbner of vias versus size. In some boards like our Merrick1 where we used a brick dc/dc, instead of an on-board regulator approach, we can have 50A going though a single hole / leg. It does help a lot having the leg to carry current but still means a lot of current in a local board area to handle. Something to consider are copper filled vias when dc loss is important. They are a specalist technique also used to reduce via losses but do come at a cost and tend to limit the number of PCB manufacturers you can use. John Adair Enterpoint Ltd. On Jan 8, 10:14=A0pm, "k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz> wrote: > On Sun, 08 Jan 2012 10:48:37 -0800, John Larkin > > > > > > > > > > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > >On Sun, 08 Jan 2012 10:53:56 -0500, legg <l...@nospam.magma.ca> wrote: > > >>On Fri, 06 Jan 2012 08:51:24 -0800, John Larkin > >><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > > >>>On Fri, 6 Jan 2012 01:55:03 -0800 (PST), "colin_toog...@yahoo.com" > >>><colin_toog...@yahoo.com> wrote: > > >>>>Guys > > >>>>I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power > >>>>plane. It is showing a 30mV voltage drop across the BGA itself, let > >>>>alone getting the power to the BGA which is dropping another 50mV. > > >>>>Surely the 30mV cannot be true as there is a power plane in the BGA > >>>>package itself. > > >>>>Historically I would look at the size of the plane and assume that > >>>>everything is fine and I can't help wondering whether this worst case > >>>>analysis is a bit pointless. > > >>>>Any opinions? > > >>>>BTW I'm already just beyond the PCB thickness I'm allowed so I can't > >>>>just use thicker copper. > > >>>>Colin > > >>>>PS. sorry about using Google, I'm sitting in the UK behind a firewall > >>>>controlled by an Indian call centre. > > >>>How much current are you expecting in the core? > > >>>What do mean by "30mV voltage drop across the BGA itself" ? Does that > >>>mean PCB plane drop, or rather BGA balls to chip internal voltage? > > >>>The chip vendors should give us one remote-sense feedback/measurement > >>>ball. > > >>>John > > >>You can probably already take your pick.....if you sacrifice the > >>immediate local signal functions. > > >>RL > > >I can sense an I/O bank supply voltage by just pulling an output up, > >but core voltage is harder to get at. I could swipe one ball out of, > >say, ten paralleled ones, I guess, if I were sure they were really > >paralleled. > > Probably not a good idea. =A0You'll be leaving one corner of the power me= sh > sagging. =A0A sense to the pad might not be a bad idea, though. =A0...if = you can > control the regulator. > > >Are core voltages segmented on most FPGAs, or are all the Vcc_core > >balls connected to one power net? > > Paralleled.Article: 153218
On Jan 5, 11:30=A0am, Tim Wescott <t...@seemywebsite.com> wrote: > Yes. =A0When you write software you should be thinking in the back of you= r > mind what the processor will be doing (and possibly what the compiler's > optimizer will do, first). =A0When you write Verilog or VHDL you should b= e > thinking in the back of your mind what logic will be generated. =A0I have > to admit that when I do this most of the blocks have "74HCxx" on them, > but you still want to devote part of your brain to thinking what actual > hardware will get used: it keeps you from doing really stupid things. I write vhdl a lot more than 2% of the time, and I share your anti- wizard approach for almost everything unless it is built-in HW that can only be accessed by primitives, like PLL/DLL, some two-clock FIFOs or that use two different data widths, etc. More often than not, I need some little special behavior for my specific application that precludes using the built-in stuff anyway, so I infer the RAM and roll my own control. Dealing with data in arrays is so much easier anyway. I found out a long time ago that thinking about and then coding function and cycle-based behavior, rather than flops and gates, is more productive for me. When I need the utmost in performance (rarely), I normally use retiming, and it doesn't matter where/how I coded the registers anyway. If I need to speed it up, I normally approach it to see "what can I do ahead of time (in a previous clock cycle)?", or "what can I delay (into the next clock cycle)?", while I look for areas that I'm doing too much in one clock cycle. Unlike SW, where you generally don't want to do something until and unless you really need to, in HW it is almost the opposite. Do it just in case, then use the results when you need them. This generally results in less logic in the function, and therefore faster performance. AndyArticle: 153219
Hi,
I have SRAM connected to a FPGA.
The clock is forwarded to the SRAM by the FPGA (using ODDR trick).
The input clock to the system is of another frequency and is
internally multiplied by a DCM.
Lets call the input clock (on the pad) clk_in and the internal DCM
generated clock clk_1x
Now, I'd like to constraint :
- The clock to out from my internal clk_1x to pad for the various
outputs
- The skew between all the pins. (Since I use IOB registers, it
should be constraint by design but I'd like at least a report ...)
- The valid window for capturing the incoming signals.
And somehow I can't figure out how to do these because I don't have a
"pad" that reflects my internal clock.
If I just try to put an OFFSET relative to my clk_in, then it outputs
mostly garbage because the clk_in and clk_1x have different
frequencies and so it tries to consider intemediate edges and stuff
but I don't care about that, all the design is clocked on clk_1x and
not clk_in ...
I looked at the Xilinx example but couldn't find one that fits. Each
time they have the external clock directly feed the internal logic and
not a DCM modifying the frequency in the middle.
Cheers,
Sylvain
Article: 153220Hi, Probably most Linux users working with Xilinx tools use the excellent drivers written by Michael Gernoth and available at http://rmdir.de/~michael/xilinx/ I'm looking for a way to embed the whole USB<->JTAG converter into device, so design should cheap and efficient. Last time I started to use them with FT2232H chip connected directly to the JTAG pins of FPGA. The result were acceptable, but speed was quite low. I think, that significant improvement could be achieved by using CPU driven JTAG hardware instead of FT2232H - e.g. the opendous-jtag http://code.google.com/p/opendous-jtag/ As the drivers are open source, it should be possible to add support to opendous-jtag (maybe with slightly modified firmware). Before I start to do it myself - has anybody tried to do it before? Any hints, pitfalls? -- TIA & Regards, Wojtek ZabolotnyArticle: 153221
"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote:
>Hi,
>
>I have SRAM connected to a FPGA.
>The clock is forwarded to the SRAM by the FPGA (using ODDR trick).
>The input clock to the system is of another frequency and is
>internally multiplied by a DCM.
>Lets call the input clock (on the pad) clk_in and the internal DCM
>generated clock clk_1x
>
>Now, I'd like to constraint :
>
> - The clock to out from my internal clk_1x to pad for the various
>outputs
You can't. You must specify FF to PAD. The path between a flipflop and
an output isn't covered by a clock domain.
TIMEGRP "all_ff" = ffs("*");
TIMEGRP "trigger_analog_pad" = pads("trigger_analog_out");
TIMESPEC "TStrigger_analog_out" = FROM "all_ff" TO
"trigger_analog_pad" 7;
> - The skew between all the pins. (Since I use IOB registers, it
>should be constraint by design but I'd like at least a report ...)
See above. The path between an input and a flipflip isn't covered by a
clock domain.
> - The valid window for capturing the incoming signals.
You have to calculate this by hand.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Article: 153222(repost from XLNX forum) Has anyone succesfully managed to program the eFuses? On the Virtex-6 in particular but any device would be good... There seems to be many restrictions and I am unclear if I am violating one of them. If you have managed to program eFuse please respond with: Device Impact Version JTAG scan chain Anything else that might help. Thanks, TomArticle: 153223
>Is there any particular reason to compile your own libusb instead of
>using the distribution packages?
>
>To make the Xilinx JTAG cable working in the RHEL/CentOS/SL 6.x do the
>following stops. There is detailed description on my website
>http://www.sensor-to-image.cz/doku.php?id=3Deda:xilinx but unfortunately
>it is in Czech language only. Sorry.
>
>1. Install and "fix" libusb:
>
>yum install libusb libusb1 fxload
>cd /usr/lib64 (or /usr/lib if you are running 32b system)
>ln -s libusb-1.0.so.0.0.0 libusb.so
>
>2. "Fix" the Xilinx cable setup script
><xilinx_install_dir>/ISE_DS/ISE/bin/lin64/setup_pcusb (or the same path
>with lin instead of lin64) which does not detect udev correctly:
>
># Use udev always
>#TP_USE_UDEV=3D"0"
>#TP_UDEV_ENABLED=3D`ps -e | grep -c udevd`
>TP_USE_UDEV=3D"1"
>TP_UDEV_ENABLED=3D"1"
>
>3. Run the script from its directory:
>
>cd <xilinx_install_dir>/ISE_DS/ISE/bin/lin64/setup_pcusb (or lin instead
>of lin64)
>./setup_pcusb
>
>4. Generated udev rule uses wrong syntax. The rule for current version
>of udev /etc/udev/rules.d/xusbdfwu.rules must look like this (long lines
>must be retained, see my website for proper formatting):
>
># version 0003
>ATTR{idVendor}=3D=3D"03fd", ATTR{idProduct}=3D=3D"0008", MODE=3D"666"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0007", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusbdfw=
>u.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0009", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xu=
>p.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"000d", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_em=
>b.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"000f", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xl=
>p.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0013", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xp=
>2.hex -D $tempnode"
>SUBSYSTEM=3D=3D"usb", ACTION=3D=3D"add", ATTR{idVendor}=3D=3D"03fd",
ATTR{i=
>dProduct}=3D=3D"0015", RUN+=3D"/sbin/fxload -v -t fx2 -I
/usr/share/xusb_xs=
>e.hex -D $tempnode"
>
>5. Connect/reconnect your cable, check dmesg, test iMPACT/ChipScope.
>
>Regards,
>Jan
>
>
>Sorry if the post appears twice. I had some problems posting the
>message.
>
>
>
Jan,
Thanks for the tutorial. Im attempting to do the same thing with
SL6.1/CentOS6/RHEL6 and the Xilinx 10.1.03 tools with no success. After I
configure everything as you prescribe when I run impact and try to read the
jtag chain it bombs and says "Module windrvr6 is not loaded. Please
reinstall the cable drivers". Your solution should bypass the windrvr6
module correct? Any idea why it would still be looking for it?
Thanks,
Nat
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 153224It looks like you have a Xilinx preference, but if you willing to try other FPGA vendors, Terasic.com has some surprisingly low-cost Altera FPGA development boards. I bought their DE2-70 board and really like it. It is in your price range and has some of the features you want, such as video out. It has a Cyclone IV FPGA that is much larger than the Spartan FPGAs you mentioned. Also, Altera's free version of Quartus II (their synthesis/place&route tools) supports the device on the DE2-70. As far as delivery time, they are based in Taiwan. Mine took a few weeks for delivery to the US. Good luck! >Hello, > >I am trying to decide what board to order for a project I want to do betwee= >n April and June in school, and for other projects, mainly to exercise VHDL= > and design interesting projects. The school project itself is the design o= >f a general purpose DSP data path. > >I have currently staked out the following boards, based upon the features I= > need and the price. > >Digilent | Atlys | >Enterpoint | Drigmorn-3 | >Xilinx | 3A Starter kit | >Enterpoint | Drigmorn-2 | >Xilinx | 3E Starter kit | > >However, also delivery time and ease of ordering are somewhat necessary, an= >d three of the five boards come from the US, while 2 come from the UK, and = >I live in Belgium. > >On the other hand, the Drigmorn boards do not feature a video output (whate= >ver type), which is also something I would like to have. > >And then there is the choice of FPGA: > > LX16 XC3S700A >Logic cells: 14579 13248 >Slices : 2278 5888 >Block RAM : 576 360 >Distributed RAM: 136 92 > >Since a LX16 seems to have less slices than a XC3S700A, does that mean that= > the LX16 will reach its maximum earlier than the XC3S700A? Conversely, doe= >s the lesser amount of distributed RAM on the XC3S700A mean that it could b= >e that in a pipelined design it has less possibilities than the LX16? > >I must say, that if I have to select purely on price, this would certainly = >favor the Drigmorn-2, but does the choice of the XC3S700A FPGA in that case= > limit me in my design choices? > >And another point, I only own a MacBook Air anymore, with Linux on Virtualb= >ox and ISE inside it, but how does this translate in my choices for program= >ming the selected board? > >Regards, > >Jurgen Defurne > --------------------------------------- Posted through http://www.FPGARelated.com
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