Messages from 153150

Article: 153150
Subject: Re: D-Type Flip flop with negated Q in Webise for a schematic capture
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 12 Dec 2011 19:15:03 -0800 (PST)
Links: << >> << T >> << A >>

On Dec 12, 2:31=A0pm, Giuseppe Marullo
<giuseppe.marullonos...@iname.com> wrote:
> > adding circles. =A0It is a tools question, not a logic question.
>
> > -- glen
>
> Glen, exactly. I need to do the capture thing because it is not so
> trivial to convert the schematic into verilog at first glance, and the
> FF uses both Q and Qbar. I was thinking it was a fault from my
> understanding of the tool, but qbar are missing on all FF i found in the
> tool.
>
> The other way would it be to write a custom block where inside a verilog
> would implement the desired FF but maybe there is a simpler way.
>
> Giuseppe Marullo

If it can be drawn in a schematic in can be written in Verilog and
probably written faster than it can be drawn.

always @ (posedge clk)
begin
   q <=3D d
end

assign qbar =3D !q;

There isn't anything unique about a Q or Qbar.  These existed at one
point in discrete logic when it was far more difficult to add an
discrete inverter on a PCB and have the inverted output was very
beneficial, but in an FPGA or ASIC it just doesn't matter anymore.  If
you need Qbar then just take Q and invert it (Qbar=3D!Q) and then apply
it to the next functional bit.  In an FPGA the inversion will be
absorbed into the next LUT function or the D, CE or RST pin of the
register that it feeds.

Note: If the Q is feeding an output buffer (OBUF) then you will need
to invert the signal going into the D of the F/F instead in order to
pack the register into the IOB.

Ed McGettigan
--
Xilinx Inc.

Article: 153151
Subject: Re: D-Type Flip flop with negated Q in Webise for a schematic capture
From: Gabor <gabor@szakacs.invalid>
Date: Tue, 13 Dec 2011 08:54:25 -0500
Links: << >> << T >> << A >>

Ed McGettigan wrote:
> On Dec 12, 2:31 pm, Giuseppe Marullo
> <giuseppe.marullonos...@iname.com> wrote:
>>> adding circles.  It is a tools question, not a logic question.
>>> -- glen
>> Glen, exactly. I need to do the capture thing because it is not so
>> trivial to convert the schematic into verilog at first glance, and the
>> FF uses both Q and Qbar. I was thinking it was a fault from my
>> understanding of the tool, but qbar are missing on all FF i found in the
>> tool.
>>
>> The other way would it be to write a custom block where inside a verilog
>> would implement the desired FF but maybe there is a simpler way.
>>
>> Giuseppe Marullo
> 
> If it can be drawn in a schematic in can be written in Verilog and
> probably written faster than it can be drawn.
> 
> always @ (posedge clk)
> begin
>    q <= d
> end
> 
> assign qbar = !q;
> 

To be true to the original, you should have written:

always @ (posedge clk)
begin
   q <= d;
   qbar <= !d;
end

In the FPGA it wouldn't matter, because the inversion would
not create another delay.  Also if you're actually copying
a schematic that was implemented in TTL, there could be other
issues if the original did not use a fully synchronous design
technique.

> There isn't anything unique about a Q or Qbar.  These existed at one
> point in discrete logic when it was far more difficult to add an
> discrete inverter on a PCB and have the inverted output was very
> beneficial, but in an FPGA or ASIC it just doesn't matter anymore.  If
> you need Qbar then just take Q and invert it (Qbar=!Q) and then apply
> it to the next functional bit.  In an FPGA the inversion will be
> absorbed into the next LUT function or the D, CE or RST pin of the
> register that it feeds.
> 
> Note: If the Q is feeding an output buffer (OBUF) then you will need
> to invert the signal going into the D of the F/F instead in order to
> pack the register into the IOB.
> 
> Ed McGettigan
> --
> Xilinx Inc.

Note that placing the inverter before or after the flip-flop
can make a difference if it actually means adding a LUT to
do the inversion, and also note that given the freedom the
synthesis tools can move the LUT before or after the flip-flop
to help meet timing (register balancing enabled).  So regardless
of how you enter the code, the result after synthesis and map
can vary.  Don't think that just because you're entering schematics
that the actual implementation will match your schematic.  At
least for FPGA's, ISE treats schematic entry just like structural
HDL and will do all of the same optimizations.  From ISE you
should also have the option to view the "technology schematic"
after translation to see what became of your "inverter".

I personally like schematic entry but detest Xilinx's implementation
of it, so I haven't used it since they dropped the Aldec front-end
tools after Foundation 4.1i.  In those days if I didn't see the
symbol I needed, I'd write Abel code and create a symbol from it.
With the newer ISE, you can also use Verilog of VHDL to enter
blocks, and then create a schematic symbol from the HDL.  Or
as suggested you can create hierarchical symbols with the
schematic editor.  There are many ways to skin a cat...

-- Gabor

Article: 153152
Subject: Re: D-Type Flip flop with negated Q in Webise for a schematic capture
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 13 Dec 2011 08:22:47 -0800 (PST)
Links: << >> << T >> << A >>

On Dec 13, 5:54=A0am, Gabor <ga...@szakacs.invalid> wrote:
> Ed McGettigan wrote:
> > On Dec 12, 2:31 pm, Giuseppe Marullo
> > <giuseppe.marullonos...@iname.com> wrote:
> >>> adding circles. =A0It is a tools question, not a logic question.
> >>> -- glen
> >> Glen, exactly. I need to do the capture thing because it is not so
> >> trivial to convert the schematic into verilog at first glance, and the
> >> FF uses both Q and Qbar. I was thinking it was a fault from my
> >> understanding of the tool, but qbar are missing on all FF i found in t=
he
> >> tool.
>
> >> The other way would it be to write a custom block where inside a veril=
og
> >> would implement the desired FF but maybe there is a simpler way.
>
> >> Giuseppe Marullo
>
> > If it can be drawn in a schematic in can be written in Verilog and
> > probably written faster than it can be drawn.
>
> > always @ (posedge clk)
> > begin
> > =A0 =A0q <=3D d
> > end
>
> > assign qbar =3D !q;
>
> To be true to the original, you should have written:
>
> always @ (posedge clk)
> begin
> =A0 =A0q <=3D d;
> =A0 =A0qbar <=3D !d;
> end
>
> In the FPGA it wouldn't matter, because the inversion would
> not create another delay. =A0Also if you're actually copying
> a schematic that was implemented in TTL, there could be other
> issues if the original did not use a fully synchronous design
> technique.
>
>
>
>
>
> > There isn't anything unique about a Q or Qbar. =A0These existed at one
> > point in discrete logic when it was far more difficult to add an
> > discrete inverter on a PCB and have the inverted output was very
> > beneficial, but in an FPGA or ASIC it just doesn't matter anymore. =A0I=
f
> > you need Qbar then just take Q and invert it (Qbar=3D!Q) and then apply
> > it to the next functional bit. =A0In an FPGA the inversion will be
> > absorbed into the next LUT function or the D, CE or RST pin of the
> > register that it feeds.
>
> > Note: If the Q is feeding an output buffer (OBUF) then you will need
> > to invert the signal going into the D of the F/F instead in order to
> > pack the register into the IOB.
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Note that placing the inverter before or after the flip-flop
> can make a difference if it actually means adding a LUT to
> do the inversion, and also note that given the freedom the
> synthesis tools can move the LUT before or after the flip-flop
> to help meet timing (register balancing enabled). =A0So regardless
> of how you enter the code, the result after synthesis and map
> can vary. =A0Don't think that just because you're entering schematics
> that the actual implementation will match your schematic. =A0At
> least for FPGA's, ISE treats schematic entry just like structural
> HDL and will do all of the same optimizations. =A0From ISE you
> should also have the option to view the "technology schematic"
> after translation to see what became of your "inverter".
>
> I personally like schematic entry but detest Xilinx's implementation
> of it, so I haven't used it since they dropped the Aldec front-end
> tools after Foundation 4.1i. =A0In those days if I didn't see the
> symbol I needed, I'd write Abel code and create a symbol from it.
> With the newer ISE, you can also use Verilog of VHDL to enter
> blocks, and then create a schematic symbol from the HDL. =A0Or
> as suggested you can create hierarchical symbols with the
> schematic editor. =A0There are many ways to skin a cat...
>
> -- Gabor- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Gabor,

Your code would generate two registers one for q and one for qbar.
IMHO, this is further removed from the original intent and would use
more resource than an inversion that would likely be merged into the
next LUT or register input.

Ed McGettigan
--
Xilinx Inc.

Article: 153153
Subject: Re: D-Type Flip flop with negated Q in Webise for a schematic capture
From: rickman <gnuarm@gmail.com>
Date: Tue, 13 Dec 2011 09:56:50 -0800 (PST)
Links: << >> << T >> << A >>

On Dec 13, 11:22=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Dec 13, 5:54=A0am, Gabor <ga...@szakacs.invalid> wrote:
>
>
>
>
>
>
>
>
>
> > Ed McGettigan wrote:
> > > On Dec 12, 2:31 pm, Giuseppe Marullo
> > > <giuseppe.marullonos...@iname.com> wrote:
> > >>> adding circles. =A0It is a tools question, not a logic question.
> > >>> -- glen
> > >> Glen, exactly. I need to do the capture thing because it is not so
> > >> trivial to convert the schematic into verilog at first glance, and t=
he
> > >> FF uses both Q and Qbar. I was thinking it was a fault from my
> > >> understanding of the tool, but qbar are missing on all FF i found in=
 the
> > >> tool.
>
> > >> The other way would it be to write a custom block where inside a ver=
ilog
> > >> would implement the desired FF but maybe there is a simpler way.
>
> > >> Giuseppe Marullo
>
> > > If it can be drawn in a schematic in can be written in Verilog and
> > > probably written faster than it can be drawn.
>
> > > always @ (posedge clk)
> > > begin
> > > =A0 =A0q <=3D d
> > > end
>
> > > assign qbar =3D !q;
>
> > To be true to the original, you should have written:
>
> > always @ (posedge clk)
> > begin
> > =A0 =A0q <=3D d;
> > =A0 =A0qbar <=3D !d;
> > end
>
> > In the FPGA it wouldn't matter, because the inversion would
> > not create another delay. =A0Also if you're actually copying
> > a schematic that was implemented in TTL, there could be other
> > issues if the original did not use a fully synchronous design
> > technique.
>
> > > There isn't anything unique about a Q or Qbar. =A0These existed at on=
e
> > > point in discrete logic when it was far more difficult to add an
> > > discrete inverter on a PCB and have the inverted output was very
> > > beneficial, but in an FPGA or ASIC it just doesn't matter anymore. =
=A0If
> > > you need Qbar then just take Q and invert it (Qbar=3D!Q) and then app=
ly
> > > it to the next functional bit. =A0In an FPGA the inversion will be
> > > absorbed into the next LUT function or the D, CE or RST pin of the
> > > register that it feeds.
>
> > > Note: If the Q is feeding an output buffer (OBUF) then you will need
> > > to invert the signal going into the D of the F/F instead in order to
> > > pack the register into the IOB.
>
> > > Ed McGettigan
> > > --
> > > Xilinx Inc.
>
> > Note that placing the inverter before or after the flip-flop
> > can make a difference if it actually means adding a LUT to
> > do the inversion, and also note that given the freedom the
> > synthesis tools can move the LUT before or after the flip-flop
> > to help meet timing (register balancing enabled). =A0So regardless
> > of how you enter the code, the result after synthesis and map
> > can vary. =A0Don't think that just because you're entering schematics
> > that the actual implementation will match your schematic. =A0At
> > least for FPGA's, ISE treats schematic entry just like structural
> > HDL and will do all of the same optimizations. =A0From ISE you
> > should also have the option to view the "technology schematic"
> > after translation to see what became of your "inverter".
>
> > I personally like schematic entry but detest Xilinx's implementation
> > of it, so I haven't used it since they dropped the Aldec front-end
> > tools after Foundation 4.1i. =A0In those days if I didn't see the
> > symbol I needed, I'd write Abel code and create a symbol from it.
> > With the newer ISE, you can also use Verilog of VHDL to enter
> > blocks, and then create a schematic symbol from the HDL. =A0Or
> > as suggested you can create hierarchical symbols with the
> > schematic editor. =A0There are many ways to skin a cat...
>
> > -- Gabor- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -
>
> Gabor,
>
> Your code would generate two registers one for q and one for qbar.
> IMHO, this is further removed from the original intent and would use
> more resource than an inversion that would likely be merged into the
> next LUT or register input.
>
> Ed McGettigan
> --
> Xilinx Inc.

I'm pretty sure most tools are smart enough to understand that the one
description is equivalent to the other and optimize the code to a
single register and shove the inversion into the following logic,
assuming there is any.  Am I wrong about this?

I know I have seen equivalent registers combined into one when I was
trying to reduce the fan out on a net.

Rick

Article: 153154
Subject: Re: D-Type Flip flop with negated Q in Webise for a schematic capture
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 13 Dec 2011 18:57:44 +0000 (UTC)
Links: << >> << T >> << A >>

Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
> On Dec 13, 5:54 am, Gabor <ga...@szakacs.invalid> wrote:

(snip)
>> To be true to the original, you should have written:

>> always @ (posedge clk)
>> begin
>>   q <= d;
>>   qbar <= !d;
>> end

>> In the FPGA it wouldn't matter, because the inversion would
>> not create another delay. Also if you're actually copying
>> a schematic that was implemented in TTL, there could be other
>> issues if the original did not use a fully synchronous design
>> technique.

  always @(posedge clk)
  begin
     q = #1 d;
     qbar = #1 !d;
  end

(snip)

>> Note that placing the inverter before or after the flip-flop
>> can make a difference if it actually means adding a LUT to
>> do the inversion, and also note that given the freedom the
>> synthesis tools can move the LUT before or after the flip-flop
>> to help meet timing (register balancing enabled). 

> Your code would generate two registers one for q and one for qbar.
> IMHO, this is further removed from the original intent and would use
> more resource than an inversion that would likely be merged into the
> next LUT or register input.

The tools are very good at removing duplicate register.  Even from
different modules at different nesting levels, they will still be
removed, such that only one is used.  (There is a message when it
does it.)

It might even be that a single register can be duplicated to help
meet the timing requirements, though I don't remember seeing it
do that.  

-- glen

Article: 153155
Subject: Re: D-Type Flip flop with negated Q in Webise for a schematic capture
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 13 Dec 2011 13:14:23 -0800 (PST)
Links: << >> << T >> << A >>

On Dec 13, 9:56=A0am, rickman <gnu...@gmail.com> wrote:
> On Dec 13, 11:22=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Dec 13, 5:54=A0am, Gabor <ga...@szakacs.invalid> wrote:
>
> > > Ed McGettigan wrote:
> > > > On Dec 12, 2:31 pm, Giuseppe Marullo
> > > > <giuseppe.marullonos...@iname.com> wrote:
> > > >>> adding circles. =A0It is a tools question, not a logic question.
> > > >>> -- glen
> > > >> Glen, exactly. I need to do the capture thing because it is not so
> > > >> trivial to convert the schematic into verilog at first glance, and=
 the
> > > >> FF uses both Q and Qbar. I was thinking it was a fault from my
> > > >> understanding of the tool, but qbar are missing on all FF i found =
in the
> > > >> tool.
>
> > > >> The other way would it be to write a custom block where inside a v=
erilog
> > > >> would implement the desired FF but maybe there is a simpler way.
>
> > > >> Giuseppe Marullo
>
> > > > If it can be drawn in a schematic in can be written in Verilog and
> > > > probably written faster than it can be drawn.
>
> > > > always @ (posedge clk)
> > > > begin
> > > > =A0 =A0q <=3D d
> > > > end
>
> > > > assign qbar =3D !q;
>
> > > To be true to the original, you should have written:
>
> > > always @ (posedge clk)
> > > begin
> > > =A0 =A0q <=3D d;
> > > =A0 =A0qbar <=3D !d;
> > > end
>
> > > In the FPGA it wouldn't matter, because the inversion would
> > > not create another delay. =A0Also if you're actually copying
> > > a schematic that was implemented in TTL, there could be other
> > > issues if the original did not use a fully synchronous design
> > > technique.
>
> > > > There isn't anything unique about a Q or Qbar. =A0These existed at =
one
> > > > point in discrete logic when it was far more difficult to add an
> > > > discrete inverter on a PCB and have the inverted output was very
> > > > beneficial, but in an FPGA or ASIC it just doesn't matter anymore. =
=A0If
> > > > you need Qbar then just take Q and invert it (Qbar=3D!Q) and then a=
pply
> > > > it to the next functional bit. =A0In an FPGA the inversion will be
> > > > absorbed into the next LUT function or the D, CE or RST pin of the
> > > > register that it feeds.
>
> > > > Note: If the Q is feeding an output buffer (OBUF) then you will nee=
d
> > > > to invert the signal going into the D of the F/F instead in order t=
o
> > > > pack the register into the IOB.
>
> > > > Ed McGettigan
> > > > --
> > > > Xilinx Inc.
>
> > > Note that placing the inverter before or after the flip-flop
> > > can make a difference if it actually means adding a LUT to
> > > do the inversion, and also note that given the freedom the
> > > synthesis tools can move the LUT before or after the flip-flop
> > > to help meet timing (register balancing enabled). =A0So regardless
> > > of how you enter the code, the result after synthesis and map
> > > can vary. =A0Don't think that just because you're entering schematics
> > > that the actual implementation will match your schematic. =A0At
> > > least for FPGA's, ISE treats schematic entry just like structural
> > > HDL and will do all of the same optimizations. =A0From ISE you
> > > should also have the option to view the "technology schematic"
> > > after translation to see what became of your "inverter".
>
> > > I personally like schematic entry but detest Xilinx's implementation
> > > of it, so I haven't used it since they dropped the Aldec front-end
> > > tools after Foundation 4.1i. =A0In those days if I didn't see the
> > > symbol I needed, I'd write Abel code and create a symbol from it.
> > > With the newer ISE, you can also use Verilog of VHDL to enter
> > > blocks, and then create a schematic symbol from the HDL. =A0Or
> > > as suggested you can create hierarchical symbols with the
> > > schematic editor. =A0There are many ways to skin a cat...
>
> > > -- Gabor- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -
>
> > Gabor,
>
> > Your code would generate two registers one for q and one for qbar.
> > IMHO, this is further removed from the original intent and would use
> > more resource than an inversion that would likely be merged into the
> > next LUT or register input.
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> I'm pretty sure most tools are smart enough to understand that the one
> description is equivalent to the other and optimize the code to a
> single register and shove the inversion into the following logic,
> assuming there is any. =A0Am I wrong about this?
>
> I know I have seen equivalent registers combined into one when I was
> trying to reduce the fan out on a net.
>
> Rick- Hide quoted text -
>
> - Show quoted text -

My preference is to write code that will match the synthesised logic.
I don't see the benefit in writing code for two registers with the
assumption that the synthesizer will remove one of them and leave the
other.  Ok, the same could be said about the inverter being absorbed
in the next stage, but for me it is easier to rationalize a function
optimization than the removal of a sequential storage element and it's
less coding and I think easier to understand when looking at
simulation waveforms.

I think that this has been beaten to death now.  Either way will
generate logical equivalent results.

Ed McGettigan
--
Xilinx Inc.

Article: 153156
Subject: Clock distribution for ADC and jitter
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Fri, 16 Dec 2011 07:59:18 -0800 (PST)
Links: << >> << T >> << A >>

Hi everyone,

I've got a question regarding clocks and jitter. Let's say I have 2
ADCs that need an input clock of 80 MHz. have an 80 MHz low-jitter
crystal connected to an FPGA and then I use the FPGA as a clock buffer
and I output the 2 clocks from the FPGA to the 2 ADCs.

We know that clock jitter is critical for high-speed ADCs, so I would
like to know, is it a good way to distribute a clock to two ADCs? Will
the FPGA add jitter? Assume I do not use any PLL in my design, the
clock goes straight from the input pin to the 2 output pins on global
routing resources. I've looked at Altera datasheet and it is not
really clear what jitter would be added by the FPGA, the only place
jitter is mentionned is for PLLs not for clock routing.

Thanks

Article: 153157
Subject: Re: Clock distribution for ADC and jitter
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 16 Dec 2011 08:31:48 -0800 (PST)
Links: << >> << T >> << A >>

On Dec 16, 7:59=A0am, Benjamin Couillard <benjamin.couill...@gmail.com>
wrote:
> Hi everyone,
>
> I've got a question regarding clocks and jitter. Let's say I have 2
> ADCs that need an input clock of 80 MHz. have an 80 MHz low-jitter
> crystal connected to an FPGA and then I use the FPGA as a clock buffer
> and I output the 2 clocks from the FPGA to the 2 ADCs.
>
> We know that clock jitter is critical for high-speed ADCs, so I would
> like to know, is it a good way to distribute a clock to two ADCs? Will
> the FPGA add jitter? Assume I do not use any PLL in my design, the
> clock goes straight from the input pin to the 2 output pins on global
> routing resources. I've looked at Altera datasheet and it is not
> really clear what jitter would be added by the FPGA, the only place
> jitter is mentionned is for PLLs not for clock routing.
>
> Thanks

The quality of the ADC sampling will be better if you distribute the
clock from the original 80 MHz source to both ADCs and the FPGA with a
dedicated clock buffer.

Ed McGettigan
--
Xilinx Inc.

Article: 153158
Subject: Re: Clock distribution for ADC and jitter
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 16 Dec 2011 11:23:52 -0600
Links: << >> << T >> << A >>

On Fri, 16 Dec 2011 07:59:18 -0800, Benjamin Couillard wrote:

> Hi everyone,
> 
> I've got a question regarding clocks and jitter. Let's say I have 2 ADCs
> that need an input clock of 80 MHz. have an 80 MHz low-jitter crystal
> connected to an FPGA and then I use the FPGA as a clock buffer and I
> output the 2 clocks from the FPGA to the 2 ADCs.
> 
> We know that clock jitter is critical for high-speed ADCs, so I would
> like to know, is it a good way to distribute a clock to two ADCs? Will
> the FPGA add jitter? Assume I do not use any PLL in my design, the clock
> goes straight from the input pin to the 2 output pins on global routing
> resources. I've looked at Altera datasheet and it is not really clear
> what jitter would be added by the FPGA, the only place jitter is
> mentionned is for PLLs not for clock routing.

I was once in a communications circuit seminar with a bunch of FPGA types 
and I asked some question about doing something that depended on the FPGA 
clocking being low jitter -- I got laughed at.

Since then I've remembered that whenever I needed to depend on clocks 
remaining pristine as the wend their ways through FPGA logic.

-- 
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.com

Article: 153159
Subject: Re: Clock distribution for ADC and jitter
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Fri, 16 Dec 2011 11:41:21 -0600
Links: << >> << T >> << A >>

>I was once in a communications circuit seminar with a bunch of FPGA types 
>and I asked some question about doing something that depended on the FPGA 
>clocking being low jitter -- I got laughed at.

I'd expect troubles from noise on the power rails if the FPGA is
running other logic.  How good/bad are they if they are only
acting as a clock switcher/divider?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Article: 153160
Subject: Re: Clock distribution for ADC and jitter
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Fri, 16 Dec 2011 11:47:56 -0800 (PST)
Links: << >> << T >> << A >>

Thank you both for your answers.

I'll put a dedicated clock buffer!

Article: 153161
Subject: High-bandwidth Digital Content (HDCP) keys with FPGA?
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Mon, 19 Dec 2011 13:06:52 +0100
Links: << >> << T >> << A >>

Does anyone know how I could safekeep HDCP keys legally by implementing the 
HDCP (and HDMI/DisplayPort) engine in FPGA?
(Yes, I know HDCP is cracked and that I can generate keys using the leaked 
master keys, but I want a legal solution)

Article: 153162
Subject: Re: Clock distribution for ADC and jitter
From: Andy <jonesandy@comcast.net>
Date: Wed, 21 Dec 2011 10:58:34 -0800 (PST)
Links: << >> << T >> << A >>

Though not a comment on jitter per se, most FPGA architectures do not
support directly connecting a global net to an output; they usually
have to go through some amount of local routing to get from the global
net to the output. The choice of local routing resources (and
therefore propagation/skew between multiple outputs) is dependent upon
what other signals are competing for those resources. You can try to
manually route them, and lock that down (ugly), but I have run into
issues where the same routing paths and delays from the global net to
the output (input of the output buffer) were not present on each
output.

One solution to this output skew problem is to use two DDR output FFs,
both clocked from the global clock net, and hard-wired to '1' on the
rising edge data input and '0' on the falling edge data input. You may
need attributes or have to instantiate the DDR primitive to keep
synthesis from trying to optimize it out. This way you are using
dedicated global routing to get to the output FF, and dedicated
circuitry from there to the pad, resulting in predictable, repeatable
delay and skew between outputs.

Like I said, this does not do anything (good) for jitter, but it does
solve skew problems, at least in a predictable, repeatable way.

Andy

Article: 153163
Subject: Re: Clock distribution for ADC and jitter
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 21 Dec 2011 21:07:21 +0000 (UTC)
Links: << >> << T >> << A >>

Andy <jonesandy@comcast.net> wrote:
> Though not a comment on jitter per se, most FPGA architectures do not
> support directly connecting a global net to an output; they usually
> have to go through some amount of local routing to get from the global
> net to the output. The choice of local routing resources (and
> therefore propagation/skew between multiple outputs) is dependent upon
> what other signals are competing for those resources. 

This is all true, but the question is jitter.  If you only have one ADC,
then skew isn't usually a problem.  Jitter can be.

I haven't seen so much discussion on sources of jitter within the
FPGA, or how it compares to other methods.  

-- glen

Article: 153164
Subject: Equivalence between "XtremeDSP48 slice" and "slices of programmable logic"
From: MN <mazouz.nezhate@gmail.com>
Date: Wed, 21 Dec 2011 21:59:58 -0800 (PST)
Links: << >> << T >> << A >>

Hi folks!
In this page (http://zone.ni.com/reference/en-XX/help/371599F-01/lvfpgaconcepts/dsp48e_top/) I've found this:

"Each DSP48E slice (Xilinx Virtex-5) is equivalent to over 500 slices of programmable logic, consumes 1/10th the power of an equivalent logic implementation".

Does anyone have the same info for XtremeDSP48 (Virtex-4)?

Thank you for your answer.

Article: 153165
Subject: Re: Equivalence between "XtremeDSP48 slice" and "slices of
From: backhus <goouse99@googlemail.com>
Date: Wed, 21 Dec 2011 23:30:41 -0800 (PST)
Links: << >> << T >> << A >>

On 22 Dez., 06:59, MN <mazouz.nezh...@gmail.com> wrote:
> Hi folks!
> In this page (http://zone.ni.com/reference/en-XX/help/371599F-01/lvfpgaconcepts/dsp...) I've found this:
>
> "Each DSP48E slice (Xilinx Virtex-5) is equivalent to over 500 slices of programmable logic, consumes 1/10th the power of an equivalent logic implementation".
>
> Does anyone have the same info for XtremeDSP48 (Virtex-4)?
>
> Thank you for your answer.

Hi,
the V4 silicon may use a different technology, but basically the same
rule applies.
A DSP48 consists of a multiplier and some adders,muxes and registers.
All of this is made as a real hardmacro, so almost no power for
configuration and storage elements is wasted like what is needed in
LUTs.(Just a few MUX config bits to bypass registers etc..)
The number of V4 Slices to create some DSP48 alike design will
probably be higher, since V$ Luts have only four inputs, while V5 LUTS
have six.

More accurate information may be derived from the V4 datasheets, or
open a thread in the forums at xilinx if no satisfying answer appears
here.

Have a nice synthesis
   Eilert

Article: 153166
Subject: Re: Equivalence between "XtremeDSP48 slice" and "slices of
From: MN <mazouz.nezhate@gmail.com>
Date: Thu, 22 Dec 2011 00:05:20 -0800 (PST)
Links: << >> << T >> << A >>

Thank you backhus for the quick answer.

Article: 153167
Subject: Re: Equivalence between
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 22 Dec 2011 10:47:15 -0600
Links: << >> << T >> << A >>

>Hi folks!
>In this page
(http://zone.ni.com/reference/en-XX/help/371599F-01/lvfpgaconcepts/dsp48e_top/)
I've found this:
>
>"Each DSP48E slice (Xilinx Virtex-5) is equivalent to over 500 slices of
programmable logic, consumes 1/10th the power of an equivalent logic
implementation".
>
>Does anyone have the same info for XtremeDSP48 (Virtex-4)?
>
>Thank you for your answer.
>

Those numbers are in the category of "marketing b**ll*x", and should not be
relied upon for any serious purpose.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153168
Subject: Xilinx virtex-5 pitfalls
From: "Finn S. Nielsen" <removethis_finnstadel@gmail.com>
Date: Fri, 23 Dec 2011 15:05:40 +0100
Links: << >> << T >> << A >>

Hello People.

Thought I'd share with you, the latest harvest of pitfalls when using 
xilinx virtex-5 (FX) FPGAs. Pitfalls that makes the difference between a 
prototype and reliable product.

1. First. When using the xps_ll_temac version 2.03a, the core does not 
have extra logic for detecting and correcting an error in the temac, 
which sometimes causes the FCS byte to be duplicated. This occurs maybe 
in 1 of 100 packets.. Cause unknown. Since the code that fixes this 
error is not included, it will cause the loss of packets due to FCS 
errors in the transmit path. Something that will kill most packet 
streaming applications.
Look at how this has been worked-around for virtex-4 and virtex-6 (yes 
the error was apparently never fixed).. and modify the code accordingly.

See also this answer record:
http://www.xilinx.com/support/answers/33456.htm

2. The proc_sys_reset core version 3.00.a is a synchronous design 
running on the "Slowest_sync_clk" input signal.

The following inputs are therefore ignored when there's no clock on the
"Slowest_sync_clk" input:

2a. Dcm_locked
2b. Ext_Reset_In
2c. Aux_Reset_In
2d. Probably all other reset inputs.

Do NOT rely on the core to reset things if there is no clock applied to 
it. This means that you should not feed the core with the output of any 
of the DCM's or PLLs which you want to monitor for the locked state.

In about one out of 100 startup situations, the signal to the PowerPC 
called "ppc_reset_bus_0_Core_Reset_Req" is not released, causing the CPU 
(and therefore usually the whole system) to HANG indefinitely.
Applying a reset to EXT/AUX_Reset_In removes the condition.

3. Depending on how fast clock sources to PLLs and DCMs start up and are 
stable, the DCM's and PLL's should be held in reset after configuration 
to ensure a stable clock. The lock outputs should also be filtered as 
they can possibly be temporarily unstable. We have never seen such 
stability but it could happen. See this forum thread: 
http://forums.xilinx.com/xlnx/board/crawl_message?board.id=Virtex&message.id=6576

4. Do not set the FPGA configuration startup sequence to wait for PLLs 
and DCMs to lock before releasing the global three state. It is not 
allowed and if selected anyway it seems that this combination is 
silently changed by bitgen.

5. If you enable the "C_STARTUP_WAIT" parameter on a DCM or PLL_ADV (not 
available on the clock generator core), the DEFAULT behaviour is for the 
startup logic to WAIT for the lock condition. The documentation says 
that NoWait is the default (obviously incorrect). To disable this 
behaviour, bitgen explicitly needs the option : -g LCK_cycle:NoWait

6. To work around the behaviour of the sys_proc_reset core, my 
recommendation would be to add the following functionality:
6a. Hold the PLLs and DCMs in reset until input clocks are stable. If 
the lock and reset pins are chained, only the first PLL/DCM is fed the 
reset signal.
6b. Also hold the EXT/AUX_reset_in inputs active until all PLLs and DCMs 
are detected to be locked and stable. Use the input clock for this (do 
not use a clock from any of the PLLs or DCMs). Or alternatively just 
wait long enough so that all PLLs and DCMs are expected to be locked. 
(see datasheet for worst case locking times (this data only exists for 
DCMs)). Applying this extra reset also works around the error with 
"ppc_reset_bus_0_Core_Reset_Req" not being released.

7. This one is not Virtex-5 specific. It's about the  xps_iic version 
2.03.a core. The reset states of the tri-state control outputs for the 
clock and data lines are only reached after the first rising edge of the 
bus clock. A zero of varying length can therefore be observed on the 
clock and/or data lines, which could cause a starting condition on the 
I2C bus. The first access to a I2C device will in that case probably 
FAIL unless all devices have an appropriate timeout . Means of 
retrying/recovering from this situation should be added to the software.

There's also a whole story about the spartan-6. But it will be another day..


Happy designing,

Finn

Article: 153169
Subject: This comp.arch.fpga group is suck - I'm leaving now
From: Mawa_fugo <ccon67@netscape.net>
Date: Tue, 27 Dec 2011 11:27:20 -0800 (PST)
Links: << >> << T >> << A >>

Dun't know why, this group being moderated or something?  But some of
my posts didn't make it.  I thinks others would experience the same
thing. Just check usenet group statistics, these days it makes about
100-200 post per month compare to its peak several years ago about
1000 - 2000 posts / month

People are leaving, so do I

bye bye

Article: 153170
Subject: Re: This comp.arch.fpga group is suck - I'm leaving now
From: Mawa_fugo <ccon67@netscape.net>
Date: Wed, 28 Dec 2011 14:32:22 -0800 (PST)
Links: << >> << T >> << A >>

On Dec 28, 9:58=A0am, "John Speth" <johnsp...@yahoo.com> wrote:
> Mr Fugo-
>
> Usenet is not moderated as far as Usenet is defined. =A0This newsgroup se=
ems
> clean to me.
>
> Lurking doesn't feed the group. =A0You appear to be a lurker. =A0It's odd=
 that
> you would disparage a newsgroup being a lurker.
>
> JJS
>
> "Mawa_fugo" =A0wrote in message
>
> news:0291069b-be5d-49e2-baf3-720874776cb3@x19g2000yqf.googlegroups.com...
>
> Dun't know why, this group being moderated or something? =A0But some of
> my posts didn't make it. =A0I thinks others would experience the same
> thing. Just check usenet group statistics, these days it makes about
> 100-200 post per month compare to its peak several years ago about
> 1000 - 2000 posts / month
>
> People are leaving, so do I
>
> bye bye

Can't imagine what my last post in this group looks like, but here it
is:

Johnsp...@yahoo.com
Activity in                     com.arch.fpga(13)

Horsepower On Tap 	  	Dec 8
Designing in Altium 	  	Feb 9
HDL float to string (sprintf %.3E)? 	  	Jul 9 2010
binary integer to ascii string in hdl? 	  	Jun 30 2010
binary integer to ascii string in hdl? 	  	Jun 25 2010
nios and ftoa() 	  	Nov 19 2009
nios and ftoa() 	  	Nov 18 2009
usb ip block vendors? 	  	Sep 30 2009
lookup table in vhdl? 	  	Jun 20 2009
lookup table in vhdl? 	  	Jun 19 2009
	  	  	  	  	  	  	 2

Article: 153171
Subject: Re: Xilinx virtex-5 pitfalls
From: Gabor <gabor@szakacs.invalid>
Date: Fri, 30 Dec 2011 09:21:38 -0500
Links: << >> << T >> << A >>

Finn S. Nielsen wrote:
> Hello People.
> 
> Thought I'd share with you, the latest harvest of pitfalls when using 
> xilinx virtex-5 (FX) FPGAs. Pitfalls that makes the difference between a 
> prototype and reliable product.
> 
> 1. First. When using the xps_ll_temac version 2.03a, the core does not 
> have extra logic for detecting and correcting an error in the temac, 
> which sometimes causes the FCS byte to be duplicated. This occurs maybe 
> in 1 of 100 packets.. Cause unknown. Since the code that fixes this 
> error is not included, it will cause the loss of packets due to FCS 
> errors in the transmit path. Something that will kill most packet 
> streaming applications.
> Look at how this has been worked-around for virtex-4 and virtex-6 (yes 
> the error was apparently never fixed).. and modify the code accordingly.
> 
> See also this answer record:
> http://www.xilinx.com/support/answers/33456.htm
> 
> 2. The proc_sys_reset core version 3.00.a is a synchronous design 
> running on the "Slowest_sync_clk" input signal.
> 
> The following inputs are therefore ignored when there's no clock on the
> "Slowest_sync_clk" input:
> 
> 2a. Dcm_locked
> 2b. Ext_Reset_In
> 2c. Aux_Reset_In
> 2d. Probably all other reset inputs.
> 
> Do NOT rely on the core to reset things if there is no clock applied to 
> it. This means that you should not feed the core with the output of any 
> of the DCM's or PLLs which you want to monitor for the locked state.
> 
> In about one out of 100 startup situations, the signal to the PowerPC 
> called "ppc_reset_bus_0_Core_Reset_Req" is not released, causing the CPU 
> (and therefore usually the whole system) to HANG indefinitely.
> Applying a reset to EXT/AUX_Reset_In removes the condition.
> 
> 3. Depending on how fast clock sources to PLLs and DCMs start up and are 
> stable, the DCM's and PLL's should be held in reset after configuration 
> to ensure a stable clock. The lock outputs should also be filtered as 
> they can possibly be temporarily unstable. We have never seen such 
> stability but it could happen. See this forum thread: 
> http://forums.xilinx.com/xlnx/board/crawl_message?board.id=Virtex&message.id=6576 
> 
> 
> 4. Do not set the FPGA configuration startup sequence to wait for PLLs 
> and DCMs to lock before releasing the global three state. It is not 
> allowed and if selected anyway it seems that this combination is 
> silently changed by bitgen.
> 
> 5. If you enable the "C_STARTUP_WAIT" parameter on a DCM or PLL_ADV (not 
> available on the clock generator core), the DEFAULT behaviour is for the 
> startup logic to WAIT for the lock condition. The documentation says 
> that NoWait is the default (obviously incorrect). To disable this 
> behaviour, bitgen explicitly needs the option : -g LCK_cycle:NoWait
> 
> 6. To work around the behaviour of the sys_proc_reset core, my 
> recommendation would be to add the following functionality:
> 6a. Hold the PLLs and DCMs in reset until input clocks are stable. If 
> the lock and reset pins are chained, only the first PLL/DCM is fed the 
> reset signal.
> 6b. Also hold the EXT/AUX_reset_in inputs active until all PLLs and DCMs 
> are detected to be locked and stable. Use the input clock for this (do 
> not use a clock from any of the PLLs or DCMs). Or alternatively just 
> wait long enough so that all PLLs and DCMs are expected to be locked. 
> (see datasheet for worst case locking times (this data only exists for 
> DCMs)). Applying this extra reset also works around the error with 
> "ppc_reset_bus_0_Core_Reset_Req" not being released.
> 
> 7. This one is not Virtex-5 specific. It's about the  xps_iic version 
> 2.03.a core. The reset states of the tri-state control outputs for the 
> clock and data lines are only reached after the first rising edge of the 
> bus clock. A zero of varying length can therefore be observed on the 
> clock and/or data lines, which could cause a starting condition on the 
> I2C bus. The first access to a I2C device will in that case probably 
> FAIL unless all devices have an appropriate timeout . Means of 
> retrying/recovering from this situation should be added to the software.
> 
> There's also a whole story about the spartan-6. But it will be another 
> day..
> 
> 
> Happy designing,
> 
> Finn

   I've been designing with Xilinx parts for so long that I forget where
I first found this information, but a DCM requires a reset of at least
3 cycles of its input clock.  This infers that the clock is already
running when the reset is applied.  3 cycles of a non-running clock
would be forever...

   For anything other than an on-board crystal oscillator, which is
generally up and running long before you can finish configuring a
Virtex 5 part, I always add a reset circuit that consists of a
counter that is held reset when the DCM is locked and the DCM status
shows the input clock is running (the lock output won't toggle if
the input clock is removed).  The counter counts up otherwise and
causes a reset of the DCM when it nears max count, but (important)
the counter is allowed to wrap.  Also important: the counter is
clocked on a constant clock that does not come from a DCM output.
The DCM outputs do not toggle while the DCM is being reset.  The
counter must be large enough that it gives the DCM time to lock
between assertions of reset when the counter wraps.

-- Gabor

Article: 153172
Subject: Regarding FFT & IFFT CORE IN XILINX
From: "varun_agr" <VARUN_AGR@n_o_s_p_a_m.n_o_s_p_a_m.YAHOO.COM>
Date: Tue, 03 Jan 2012 04:13:41 -0600
Links: << >> << T >> << A >>

Sir
I am trying to use FFT 5.0 core in xilinx as follows for 50 hz Sin
WAVE(THROUGH ADC)for noise removal
1. 64 Transform size
2. Radix-2 burst mode
3.I/p data width 8 bit
4.Scaled
5. Natural order(without cylix prefix)
I want to know what is the value of scale_sch.
Further I want to use inverse FFT for the O/P fft i.e XK_REAL AND XK_IMA.
and display the same sine wave via DAC. So what is the procedure after
FFT.
Should I remove all real and imaginary except fundamental frequency i.e
calculated by xk_index.
and give this to FFT core(for inverse FFT) or anything else, kindly suggest
me
bye
Varun

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153173
Subject: Verilog module in VHDL project - ISE 13
From: Mike Harrison <mike@whitewing.co.uk>
Date: Tue, 03 Jan 2012 12:49:37 +0000
Links: << >> << T >> << A >>

I want to use the Xilinx Spartan-6 XAPP495 HDMI/DVI transmit/receive modules, which are written in
Verilog,  in a new VHDL project, as I'm much more familiar with VHDL - I don't do enough FPGA stuff
to justify the time to learn a new language for one project.

Can anyone point me towards how I can  include the verilog modules and make the signals visible to
my VHDL - any example of a verilog module included in a VHDL project would probably give me enough
to go on.

Article: 153174
Subject: Re: DEBUG a FIFO output on Virtex5 using CHIPESCOPE
From: Gabor <gabor@szakacs.invalid>
Date: Tue, 03 Jan 2012 08:30:24 -0500
Links: << >> << T >> << A >>

fanakin wrote:
> Hi All,
> I'm a relatively newbe of FPGA development.
> We are working on a design involving BFSK modulator / demodulator pair.
> We are usign the built-in FIFO18 component of Xilinx for Virtex5.
> For some reason the fifo output seems to be NOT proper.
> Could any of you suggest a way to investigate this, maybe using chipscope?
> I tried to connect the Data output of the fiso to an ILA driven by read
> clock but the clock is much faster than the read enable signal so I see a
> lot of samples of the same value.
> Any adie about hot to do?
> 
> Thanks a lot in advance
> 
> Best regards
> 
> Fabio Giovagnini
> Aurion s.r.l.
> Bologna (Italy)
> 
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

ChipScope has a feature that allows you to collect data only on cycles
that match a certain condition.  This conditional storage uses the
same trigger logic as the normal trigger, so it is convenient to
define multiple triggers when you generate the ILA core.  You can
use the read enable of the FIFO as a condition for storage.  If
you also want to see surrounding cycles, you may need to add logic
to generate the storage condition you want, and just make sure to
place a KEEP attribute on the signal so it is available to ChipScope.

-- Gabor

Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources

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

Custom Search