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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Messages from 105700

Article: 105700
Subject: Re: Hardware book like "Code Complete"?
From: Paul Floyd <root@127.0.0.1>
Date: 28 Jul 2006 20:39:14 GMT
Links: << >>  << T >>  << A >>
On Fri, 28 Jul 2006 11:33:25 -0700, Mike Treseler
   <mike_treseler@comcast.net> wrote:
> BobG wrote:
>> I read the whole thread and no one recommended "The Art Of Electronics"
>> by Horowitz and Hill??
>
> That's more of an electronics book than an RTL book.

It _is_ an electronics book. There is one mention of RTL, but it's
'resistor-transistor logic'. Not quite the same thing.

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.

Article: 105701
Subject: Re: Spartan3 5V PCI
From: "yy" <yy7d6@yahoo.com.ph>
Date: 28 Jul 2006 13:56:58 -0700
Links: << >>  << T >>  << A >>

Ayon kay PeteS:
> yy wrote:
> > Hi,
> > I have a Working Universal PCI Evaluation Kit (Spartan3) without any
> > Bus Switches/resistors etc. The package name is 'TruePCI', and it works
> > fine with a motherboard that have 5V slots. The bank VCCO of Spartan 3
> > is wired to +3.3V, many have said that bus switches are needed in order
> > to connect Spartan 3 to PCI? But then this board seems to work pretty
> > well, Any ideas? BTW, what i'm building is a specialized pci board.
> >
> > Thanks.
>
> Bus switches may be necessary in a system that pushes the PCI spec to
> it's limits. What you can get away with on an eval kit is not what you
> can get away with if you are making something that is required to meet
> the PCI 2.2. Spec.
>
> Note very carefully that you can get away with a LOT at 5V that simply
> won't work at 3.3V, and indeed vice versa. I had an 'improved' part
> some years ago from Intel where it quit working in an existing design
> at 3.3V. Apart from that, have you tried it with a unit that has 3.3V
> slots (to match your VIO)? That's a completely different test than you
> are doing.
>
> You don't say what the board you are designing is: is it a drop-in PCI
> board, or a self contained unit that has a PCI interface between some
> units on it? If it's self contained, there are things you can get away
> with as you don't have to interface to the outside world (been there,
> done that).
>
> Cheers
>
> PeteS

PeteS,
 It is a PCI master/target card connected to an SBC(Single Board
Computer) with 5V PCI.
The SBC has only one edge (male edge) such that i will be designing the
board to have an edge connector(female). 
-yy


Article: 105702
Subject: large data access to SDRAM at fixed frequency
From: "mpierrotb" <pm.boyer@wanadoo.fr>
Date: 28 Jul 2006 14:52:03 -0700
Links: << >>  << T >>  << A >>
Hi !
I am new in electronique.
I want to make an analog acquisition board with an ARM microcontroler (
Samsung S3C44B0x 66MHz) with
a 8Mbytes SDRAM and an A/D converter( Analog AD775 ).
The sampling rate of the A/D converter is at 30Mhz, and i would like to
connect its digital output to the S3c44b0x
data bus by using the DMA of the uC.
Data sent by the ADC will be wrote to the SDRAM by using the DMA of uC.
But the number of sampling can be very large, and the
acquisition/transfert occur at a fixed rate (30 Mhz).
The acquisition time and transfert to SDRAM can be more than 64ms
(refresh time cycle of SDRAM).

So, my question is :  is the internal refresh cycle of SDRAM can
disturb the data writing by the DMA to the SDRAM ?
The ADC send data to the SDRAM through the DMA at a fixed rate during
may be 1 or 2 second, and is this process
can be stopped/disturbed by the internal refresh process of SDRAM ?

If yes, is there a solution, to manage the two process ( fixed
acquisition and SDRAM refresh cycle) ?

Thank you very much.


Article: 105703
Subject: Re: Hardware book like "Code Complete"?
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 28 Jul 2006 16:15:48 -0700
Links: << >>  << T >>  << A >>
Hi Mike,
Thank you.

Weng



mikegurche@yahoo.com wrote:
> You can assignee an initial value when a variable or signal is
> declared, e.g.,
>
> signal mysig: std_logic := '0';
>
> This will be the initial value when simulation starts.  According to
> VHDL LRM, if there is no initial value, the first value defined in the
> data type will be used.  Since std_logic is defined as ('U', 'X', '0',
> ...) in 1164 package.  The 'U' value (for uninitialized) will be the
> default value.
>
> Since the initial value cannot always be synthesized, this approach
> should not be used in synthesis.  It is better to use an explicit reset
> mechanism to initialize a sequential circuit.
>
> Mike G.
>
>
> Weng Tianxiang wrote:
> > Hi Mike,
> > Thank you for your response.
> > Now what is the first value after system asynchronous reset for first
> > loop?
> >
> > Thank you.
> >
> > Weng
> >
> > Mike Treseler wrote:
> > > Weng Tianxiang wrote:
> > >
> > > > In the following statement:
> > > >   var := (var - 1) mod var_limit;
> > > > var is not assigned any value before it is used. var_limit is a
> > > > constant, of course.
> > > > Anything is wrong?
> > >
> > > No.
> > > For simulation, the present value is used
> > > to calculate and save the expression value.
> > > For synthesis, this is infers a register to save
> > > the value for the next process loop.
> > > 
> > >     -- Mike Treseler


Article: 105704
Subject: Re: Verilog case statements
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 28 Jul 2006 16:34:46 -0700
Links: << >>  << T >>  << A >>
RobJ wrote:
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:1154099086.215982.7080@m79g2000cwm.googlegroups.com...
> > While reviewing the code that the FPGA group has produced, I saw
> > something that looks bad.  It is not likely to affect the
> > functionality, but it is not good coding style and may use extra
> > resources.
> >
> > They are using Verilog which is not my first HDL language and I am not
> > as familiar with it as I am VHDL.  But because the case statement is
> > not fully specified the code below appears to me to produce more
> > complex logic than needed.
> >
> > always @ (negedge rst_n or posedge clk) begin
> >  if (!rst_n)begin
> >    mask_wr      <= 1'b0;
> >    clear_wr      <= 1'b0;
> >    end
> >  else begin
> >    if (wr == 1'b1)begin
> >      case (adr [2:1])
> >        MASK:     mask_wr      <= 1'b1;
> >        CLEAR:   clear_wr      <= 1'b1;
> >        endcase
> >      end
> >    else begin
> >      mask_wr      <= 1'b0;
> >      clear_wr      <= 1'b0;
> >    end
> >  end
> > end
> >
> > The real code is controlling 20 or so signals and is very large so this
> > is very simplified.  At first I didn't notice the enclosing "always"
> > statement and thought it would produce a latch.  Now I realize that it
> > will make enabled registers when what is really desired is just
> > decoders followed by registers.  I guess in the grand scheme of things
> > this is not a big issue.  But wouldn't it make a more streamlined
> > result to code the logic separate from the register?  Then the logic
> > would just be decodes of the address bus and the control signal and the
> > register would not have separate enables.
> >
>
> Rick -
>
> This looks fine to me. It's easy to read and will function correctly, plus
> the case statement and use of parameters make it easy to modify. Given what
> I've heard of your relationship with the FPGA group, I would not flag this
> if I were you. It would be nitpicking.

I never said I was going to "flag" it.  I was just asking for some help
understanding how Verilog worked.  If it were VHDL I would know for
certain how the synthesizer would handle it.  But I am pretty confident
that this will be less efficient than a properly constructed
description.

That is how I code differently from a lot of people.  Many designers
"program" in the HDL.  I design my hardware in block diagrams and use
the language to describe my hardware.  The above code certainly
functions correctly, but it would be just as clear, if not more so to
separate the logic and the register.  A register description is very,
very simple and small.  These can be put after the logic or they can be
lumped together in a register bunch at the end of the module.

The above program coded as logic would have a separate assignment for
each signal.  These assignments would not have any unspecified
conditions and so would implement very efficiently and of course no
latches.  Expand the above code to 12 address lines and 25 signals and
you will see how inefficient this could get.


Article: 105705
Subject: Re: Verilog case statements
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 28 Jul 2006 16:54:10 -0700
Links: << >>  << T >>  << A >>
John_H wrote:
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:1154101628.534694.304340@s13g2000cwa.googlegroups.com...
>
> > Two FFs and four logic elements (x15 in the real circuit).  You have to
> > use a LUT to drive the D input and you have to use a LUT to drive the
> > enable input.  Of course you can feedback the output to the input and
> > not use the clock enable, but that will also use more LUTs depending on
> > if you have the extra inputs or not on the LUTs you are using.  But
> > this will be up to the tool and many times I see the tool generating
> > logic to feed the clock enable.
> >
> > It is not a big deal.  I tend to think of things like this when I code
> > in an HDL just so I know my logic generation is lean.  Originally I had
> > not seen the enclosing always statement and was thinking it was
> > generating a latch.  Once I started looking at it I realize the latch
> > was not an issue but thought about the extra logic being generated.  I
> > tend to separate my registers from my logic just to allow me to
> > optimize this sort of thing.
>
> You're taking the code structure as a literal guide for synthesis.  There
> will be two FFs and two LUTs without a clock enable.  Synthesis typically
> knows what simple logic breaks down to and how to best implement it.  If you
> go into the technology view of your synthesizer to look at one of the flops,
> expect to see only one LUT driving it, no clock enable involved.

With this simple example you are right, it will require a single
4-input LUTs even if you don't use the CE.  The logic functions only
has four inputs and so can be done in a single 4-input LUT.  They are
wr, the two address bits and the feedback from the given register.  But
if there is one more address line the feedback will push it to a pair
of LUTs.  Like I said, it is not a huge difference, but with the large
number of signals in the real code, this could have been done very
slightly different and would have been optimal.

I realized that a simple change would not be any more typing and would
fully specify the assignments to eliminate the need for the feedback
signal.  At least if this works like VHDL it would work correctly.
Like I said, I am not up to speed in Verilog anymore.

always @ (negedge rst_n or posedge clk) begin
  if (!rst_n)begin
    mask_wr      <= 1'b0;
    clear_wr      <= 1'b0;
    end
  else begin
    mask_wr      <= 1'b0;
    clear_wr      <= 1'b0;
    if (wr == 1'b1)begin
      case (adr [2:1])
        MASK:     mask_wr      <= 1'b1;
        CLEAR:   clear_wr      <= 1'b1;
        endcase
      end
  end
end

Rather than specify the default condition in the ELSE of the if
condition, it is specified first as the default.  Then any signal that
is not assigned in the case statement will still be defined.  The above
is the intended function rather than holding the previous state of the
signal.  But then like I said in another post, I don't code behavior
and let the tools determine the logic, I describe logic which has the
behavior I want.


Article: 105706
Subject: Re: Verilog case statements
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Fri, 28 Jul 2006 21:04:06 -0400
Links: << >>  << T >>  << A >>
On Fri, 28 Jul 2006 08:04:46 -0700, rickman wrote:

> While reviewing the code that the FPGA group has produced, I saw
> something that looks bad.  It is not likely to affect the
> functionality, but it is not good coding style and may use extra
> resources.
> 
> They are using Verilog which is not my first HDL language and I am not
> as familiar with it as I am VHDL.  But because the case statement is
> not fully specified the code below appears to me to produce more
> complex logic than needed.
> 
> always @ (negedge rst_n or posedge clk) begin
>   if (!rst_n)begin
>     mask_wr      <= 1'b0;
>     clear_wr      <= 1'b0;
>     end
>   else begin
>     if (wr == 1'b1)begin
>       case (adr [2:1])
>         MASK:     mask_wr      <= 1'b1;
>         CLEAR:   clear_wr      <= 1'b1;
>         endcase
>       end
>     else begin
>       mask_wr      <= 1'b0;
>       clear_wr      <= 1'b0;
>     end
>   end
> end
> 
> The real code is controlling 20 or so signals and is very large so this
> is very simplified.  At first I didn't notice the enclosing "always"
> statement and thought it would produce a latch.  Now I realize that it
> will make enabled registers when what is really desired is just
> decoders followed by registers.  I guess in the grand scheme of things
> this is not a big issue.  But wouldn't it make a more streamlined
> result to code the logic separate from the register?  Then the logic
> would just be decodes of the address bus and the control signal and the
> register would not have separate enables.

The only problem with that code is the lack of a default statement.
Without a default statement the synthesizer will screw it up because the
undefined cases won't be treated as do nothing. If you add a default
statement then the synthesizer will do the right thing.



Article: 105707
Subject: Can I get 840HZ from a Xilinx Spartan-3's DCM? Phase locked?
From: "Nevo" <nevo_n@hotmail.com>
Date: 28 Jul 2006 20:15:37 -0700
Links: << >>  << T >>  << A >>
I need to generate signals to dim incandescent lights to one of 16
dimming levels.

I have built a 14-bit counter, which gives 16 discrete signals when
used with always-on and always-off signals. To properly dim my lights,
I need an 840Hz signal (that's the 60Hz mains frequency times 14 clock
cycles needed) to drive my 14-bit counter circuit.

(Yes, I plan on using the same solution to generate 700Hz (50Hz * 14)
for other regions of the world.)

Oh yeah, and I'd like this clock synchronized to the zero-crossing of
the mains voltage, to minimize line noise when switching loads on.

I'm looking at Appnote XAPP462 and I don't think it's going to be
possible to generate this singal on-chip. My desired output frequency
is lower than the DCM will go. I know I can divide the output of
whatever frequency I can generate, but I don't know if (or how) I can
sync with the mains zero crossing at such low frequencies.

However, I'm an amateur here and wanted to toss it out to the more
experienced crowd. Can this be done?

Thanks,

-Nevo


Article: 105708
Subject: Re: Verilog case statements
From: "RobJ" <rob@abc.net>
Date: Sat, 29 Jul 2006 04:11:30 GMT
Links: << >>  << T >>  << A >>
"Josh Rosen" <bjrosen@polybusPleaseDontSPAMme.com> wrote in message 
news:pan.2006.07.29.01.04.03.95311@polybusPleaseDontSPAMme.com...
>
> The only problem with that code is the lack of a default statement.
> Without a default statement the synthesizer will screw it up because the
> undefined cases won't be treated as do nothing. If you add a default
> statement then the synthesizer will do the right thing.
>

Gotta disagree, Josh. In a clocked process it is understood (and properly 
implemented by synthesis tools) that for undefined cases the last state of 
each register is held, which is what you want. You only need to explicitly 
code transitions. As long as the registers are initialized, which they are 
here by an async reset, then you're good to go. Even that is mainly a 
simulation issue. A synthesis tool can even handle no initialization, but 
you have to know what you're getting. In a non-clocked process you must spec 
defaults (either before the case statement or inside the case statement), or 
latches are inferred. In my opinion there is absolutely nothing wrong the 
code block Rickman posted other than asthetics (I don't care for how the 
begin/ends are indented).

Rob 



Article: 105709
Subject: Re: Can I get 840HZ from a Xilinx Spartan-3's DCM? Phase locked?
From: "RobJ" <rob@abc.net>
Date: Sat, 29 Jul 2006 04:21:34 GMT
Links: << >>  << T >>  << A >>
"Nevo" <nevo_n@hotmail.com> wrote in message 
news:1154142937.634762.135010@p79g2000cwp.googlegroups.com...
>I need to generate signals to dim incandescent lights to one of 16
> dimming levels.
>
> I have built a 14-bit counter, which gives 16 discrete signals when
> used with always-on and always-off signals. To properly dim my lights,
> I need an 840Hz signal (that's the 60Hz mains frequency times 14 clock
> cycles needed) to drive my 14-bit counter circuit.
>
> (Yes, I plan on using the same solution to generate 700Hz (50Hz * 14)
> for other regions of the world.)
>
> Oh yeah, and I'd like this clock synchronized to the zero-crossing of
> the mains voltage, to minimize line noise when switching loads on.
>
> I'm looking at Appnote XAPP462 and I don't think it's going to be
> possible to generate this singal on-chip. My desired output frequency
> is lower than the DCM will go. I know I can divide the output of
> whatever frequency I can generate, but I don't know if (or how) I can
> sync with the mains zero crossing at such low frequencies.
>
> However, I'm an amateur here and wanted to toss it out to the more
> experienced crowd. Can this be done?
>
> Thanks,
>
> -Nevo
>

Hi Nevo -

A 14-bit counter does not cycle every 14 clock cycles. It rolls over every 
2^14 clock cycles. It really sounds like you want a 4-bit counter counting 
modulus 14 and driving 14 PWM outputs (plus your always-on and always-off 
outputs). I didn't look at XAPP462 so I don't know what you're referring to 
there, but if you need to multiply the mains frequency to generate a clock, 
see the recent thread with the subject line "2KHz clock signal from 50Hz 
main frequency with ADPLL".

Rob 



Article: 105710
Subject: Re: Does MAC FIR filter need special care?
From: "Sophi" <joy.li@student.adelaide.edu.au>
Date: 28 Jul 2006 23:59:02 -0700
Links: << >>  << T >>  << A >>
MM wrote:
> Decimation used not to work in MAC FIR until certain version. I believe it
> should have been fixed in v5.1. It might be that you are using an old core.
>
> /Mikhail

Hi Mikhail,

I am in fact using version 5.1 logicCore. So, I don't think that's the
problem. But thank you for your help anyway.

Sophi :)


Article: 105711
Subject: Re: Verilog case statements
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 29 Jul 2006 10:29:22 +0200
Links: << >>  << T >>  << A >>
rickman wrote:

> always @ (negedge rst_n or posedge clk) begin
>   if (!rst_n)begin
>     mask_wr      <= 1'b0;
>     clear_wr      <= 1'b0;
>     end
>   else begin
>     mask_wr      <= 1'b0;
>     clear_wr      <= 1'b0;
>     if (wr == 1'b1)begin
>       case (adr [2:1])
>         MASK:     mask_wr      <= 1'b1;
>         CLEAR:   clear_wr      <= 1'b1;
>         endcase
>       end
>   end
> end

But this is different to the initially posted code example! In the 
inital example both FFs hold their old values in some circumstances 
while now everytime a value is assigned to their inputs. Therefore this 
is a functional simplification which can only be done if the resulting 
behavior is acceptable.

If acceptable it seems to me to be a good way to code this.


Ralf

Article: 105712
Subject: Re: "This design element is inferred rather than instantiated" (newbie)
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 29 Jul 2006 10:38:11 +0200
Links: << >>  << T >>  << A >>
Nevo wrote:


> For instance, if I want a D4_16E (a 4-bit one-of-sixteen decoder) in my
> project, how would I do that?

I would recommend to leave this work to the synthesis tool and write a 
simple case-statement or an if-then-else-statement.

always @(sel, inp_0, ..., inp_f)
begin
case (sel)
4'h0 : sig <= inp_0;
4'h1 : sig <= inp_1;
...
4'hf : sig <= inp_f;
endcase
end //always


If the 16 inputs are concatenated in a vector you could also use a 
for-loop to select the desired bit.


Ralf

Article: 105713
Subject: Re: Verilog case statements
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 29 Jul 2006 01:44:21 -0700
Links: << >>  << T >>  << A >>
RobJ wrote:
> "Josh Rosen" <bjrosen@polybusPleaseDontSPAMme.com> wrote in message
> news:pan.2006.07.29.01.04.03.95311@polybusPleaseDontSPAMme.com...
> >
> > The only problem with that code is the lack of a default statement.
> > Without a default statement the synthesizer will screw it up because the
> > undefined cases won't be treated as do nothing. If you add a default
> > statement then the synthesizer will do the right thing.
> >
>
> Gotta disagree, Josh. In a clocked process it is understood (and properly
> implemented by synthesis tools) that for undefined cases the last state of
> each register is held, which is what you want. You only need to explicitly
> code transitions. As long as the registers are initialized, which they are
> here by an async reset, then you're good to go. Even that is mainly a
> simulation issue. A synthesis tool can even handle no initialization, but
> you have to know what you're getting. In a non-clocked process you must spec
> defaults (either before the case statement or inside the case statement), or
> latches are inferred. In my opinion there is absolutely nothing wrong the
> code block Rickman posted other than asthetics (I don't care for how the
> begin/ends are indented).

Ah, but the unspecified cases are where the code is not doing what was
intended.  In the code posted, the previous value will be held.
Instead the intent was that the value should always be 0 except for the
decodes specified in the case statement.  It was just luck that the
input conditions never create a failure.  As long as the address
remains constant while the wr strobe is asserted, it will not have to
"remember" a value.  That is why I said this would not work so well for
the read decodes.


Article: 105714
Subject: Re: Issues w/ 8 lane Aurora sample design
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sat, 29 Jul 2006 14:08:44 +0200
Links: << >>  << T >>  << A >>
billu schrieb:
> Just checked. I think they are ok ... 4 MGTs on the top use
> TOP_BREF_CLK (pins B14 and C14) and 4 MGTs on the bottom row use
> BOTTOM_BREF_CLK2 (pins AE13 and AD13)
> 
> The same code works for a ML310 board, so I'm guessing there some
> specific board related issue.
> 
> Any tips?

Did you select the right device and packages in the project settings?

Regards
Falk

Article: 105715
Subject: Re: large data access to SDRAM at fixed frequency
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sat, 29 Jul 2006 14:10:44 +0200
Links: << >>  << T >>  << A >>
mpierrotb schrieb:

> If yes, is there a solution, to manage the two process ( fixed
> acquisition and SDRAM refresh cycle) ?

I guess you need a inbetween controller with some amount of buffer (FIFO).

Regards
Falk

Article: 105716
Subject: Re: 2Khz clock signal from 50Hz main frequency with ADPLL
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sat, 29 Jul 2006 14:21:26 +0200
Links: << >>  << T >>  << A >>
raso schrieb:

>>>More or less. Wait a tick. Look at the data sheet of the 74xx297, it
>>>says the lock range (pull range) of the PLL is
>>>delta_f_max = fc * M / (2*K*N )
>>>using your values
>>>delta_f_max = 50 Hz * 600000 / (2* 300000 * 40) = 1.25 Hz
>>>Hmm, this should be enought.
> 
> 
> I/D counter is a 2 divider.  In locked condition, its output is 30MHz/2
> = 15MHz.
> Therefore, in addition to N=40 divider, I have to use an f_out
> prescalar (=7500). In
> this case :
> 
> delta_f_max = fc * M / (2*K*N*f_out_prescalar )
> delta_f_max = 50 Hz * 600000 / (2* 300000 * 40 * 7500) = 1.25/7500 Hz
> 
> Is this correct?

Hmm, I think so. Pretty narrow pull range. You need to decrease K.

Regards
Falk

Article: 105717
Subject: Re: Verilog case statements
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Sat, 29 Jul 2006 08:27:29 -0400
Links: << >>  << T >>  << A >>
On Sat, 29 Jul 2006 04:11:30 +0000, RobJ wrote:

> "Josh Rosen" <bjrosen@polybusPleaseDontSPAMme.com> wrote in message 
> news:pan.2006.07.29.01.04.03.95311@polybusPleaseDontSPAMme.com...
>>
>> The only problem with that code is the lack of a default statement.
>> Without a default statement the synthesizer will screw it up because the
>> undefined cases won't be treated as do nothing. If you add a default
>> statement then the synthesizer will do the right thing.
>>
> 
> Gotta disagree, Josh. In a clocked process it is understood (and properly 
> implemented by synthesis tools) that for undefined cases the last state of 
> each register is held, which is what you want. You only need to explicitly 
> code transitions. As long as the registers are initialized, which they are 
> here by an async reset, then you're good to go. Even that is mainly a 
> simulation issue. A synthesis tool can even handle no initialization, but 
> you have to know what you're getting. In a non-clocked process you must spec 
> defaults (either before the case statement or inside the case statement), or 
> latches are inferred. In my opinion there is absolutely nothing wrong the 
> code block Rickman posted other than asthetics (I don't care for how the 
> begin/ends are indented).
> 
> Rob

I can tell you from first hand experience that the current version
(8.2sp1) of XST mishandles case statements that don't have defaults, I
just ran into the problem. I've seen this happen before with other
synthesizers. It's just good practice to include a default in a case
statement. That default can be empty but it's presence tell the
synthesizer that the states don't change for the un-specified cases.

Article: 105718
Subject: Interfacing Spartan3 FPGA to 5V PCI
From: "yy" <yy7d6@yahoo.com.ph>
Date: 29 Jul 2006 06:40:30 -0700
Links: << >>  << T >>  << A >>
Hi,
is setting the Vcco of Spartan3 banks to +3.3V would allow the FPGA to
work with a 5V signaling environment like 5V PCI? Or there are some
other means to do this?

Thanks.


Article: 105719
Subject: Re: Verilog case statements
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 29 Jul 2006 06:54:08 -0700
Links: << >>  << T >>  << A >>
Ralf Hildebrandt wrote:
> rickman wrote:
>
> > always @ (negedge rst_n or posedge clk) begin
> >   if (!rst_n)begin
> >     mask_wr      <= 1'b0;
> >     clear_wr     <= 1'b0;
> >     end
> >   else begin
> >     mask_wr      <= 1'b0;
> >     clear_wr     <= 1'b0;
> >     if (wr == 1'b1)begin
> >       case (adr [2:1])
> >         MASK:     mask_wr      <= 1'b1;
> >         CLEAR:    clear_wr     <= 1'b1;
> >         endcase
> >       end
> >   end
> > end
>
> But this is different to the initially posted code example! In the
> inital example both FFs hold their old values in some circumstances
> while now everytime a value is assigned to their inputs. Therefore this
> is a functional simplification which can only be done if the resulting
> behavior is acceptable.
>
> If acceptable it seems to me to be a good way to code this.

That was the point.  The initial code was not coded correctly for the
intended behavior.  It only worked in the application (so far) because
the address did not change.  This is just a set of address decodes
feeding into a register.  It is intended to be clocked on every clock
cycle.  In fact if I gave it a bit of thought, I would remove the
enclosing IF and make the signal assignments from the WR signal...

always @ (negedge rst_n or posedge clk) begin
  if (!rst_n)begin
    mask_wr     <= 1'b0;
    clear_wr    <= 1'b0;
    end
  else begin
    mask_wr     <= 1'b0;
    clear_wr    <= 1'b0;
    case (adr [2:1])
      MASK:    mask_wr     <= wr;
      CLEAR:   clear_wr    <= wr;
      endcase
  end
end

Now the code is doing exactly what it should be doing, anding the
addresses signals with the wr to produce a decode which is then
registered without an enable.  This is totally clear and will produce
the optimally minimum logic.  Another advantage is that you can easily
combine the read and the write strobes in the same block if the design
were small enough to make that useful.  There are many registers in
this design so it would produce too large of a list to combine them.


Article: 105720
Subject: Re: Can I get 840HZ from a Xilinx Spartan-3's DCM? Phase locked?
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 29 Jul 2006 16:40:00 +0200
Links: << >>  << T >>  << A >>
Nevo wrote:

> I need to generate signals to dim incandescent lights to one of 16
> dimming levels.

I don't think that 16 levels are sufficient for dimming, because it be
logarithmic: If the lamp is dim, small changes in the pulse width may cause
larger brightness perception than if the lamp is already bright. So I
suggest to use 256 steps and using a lookup table, if your controll unit
has 16 steps.

> I know I can divide the output of
> whatever frequency I can generate, but I don't know if (or how) I can
> sync with the mains zero crossing at such low frequencies.

For such low frequencies you can measure it and adjust a divider for every
rising reference clock edge:


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity pll is
  generic(multiplier,
          reference_clock_frequency,
          system_clock_frequency: natural);
  port(
    reference_clock: in std_logic;
    system_clock: in std_logic;
    clock_out: out std_logic);
end entity pll;

architecture rtl of pll is

  signal system_clock_counter: unsigned(31 downto 0) := (others => '0');
  signal system_clock_divider: unsigned(31 downto 0) :=
     to_unsigned(system_clock_frequency /
                 (multiplier * reference_clock_frequency) / 2, 32);
  signal clock_counter: unsigned(15 downto 0) := (others => '0');
  signal clock_signal:  std_logic := '0';
  signal old_reference_clock: std_logic := '0';

begin
  update_counter: process(system_clock)
  begin
    if system_clock'event and system_clock = '1' then
      if old_reference_clock /= reference_clock
          and reference_clock = '1' then
        if clock_counter > multiplier * 2 then
          system_clock_divider <= system_clock_divider + 1;
        else
          if clock_counter < multiplier * 2 then
            system_clock_divider <= system_clock_divider - 1;
          end if;
        end if;
        clock_counter <= (others => '0');
        old_reference_clock <= reference_clock;
      else
        if system_clock_counter >= system_clock_divider then
          system_clock_counter <= (others => '0');
          clock_signal <= not clock_signal;
          clock_counter <= clock_counter + 1;
        else
          system_clock_counter <= system_clock_counter + 1;
        end if;
        old_reference_clock <= reference_clock;
      end if;
    end if;
  end process;
  
  clock_out <= clock_signal;
end architecture rtl;


And a simple dimmer, which turns the lamp on with rising edge of the
reference clock, could look like this:


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity dimmer is
  port(
    clock50hz: in std_logic;
    clock_x_256: in std_logic;
    on_time: in unsigned(7 downto 0);
    lamp: out std_logic);
end entity dimmer;

architecture rtl of dimmer is

  signal counter: unsigned(7 downto 0) := (others => '0');
  signal counter_max: unsigned(7 downto 0) := (others => '0');
  signal old_clock50hz: std_logic := '0';

begin
  update_counter: process(clock_x_256)
  begin
    if clock_x_256'event and clock_x_256 = '1' then
      if old_clock50hz /= clock50hz and clock50hz = '1' then
        old_clock50hz <= clock50hz;
        counter <= (others => '0');
        counter_max <= on_time;
      else
        old_clock50hz <= clock50hz;
        if counter < counter_max then
          lamp <= '1';
          counter <= counter + 1;
        else
          lamp <= '0';
        end if;
      end if;
    end if;
  end process;
end architecture rtl;


I don't think that you need my PLL simulation, because for a simple dimmer
the only important thing is to synchronize with mains zero crossing, so you
can derive the clock_x_256 signal from the main clock, but the advantage of
the PLL is that it synchronize in some seconds automaticly to 60 Hz (or
faster, if you change the divider adjust value), without changing the VHDL
source.

Putting it all together (I'm generating the 50 Hz mains power frequency
with my clock_generator from http://www.frank-buss.de/vhdl/index.html ) I
can dim my LED on my Spartan 3E starter kit:


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity dimmer_test is
  port(
    clk_50mhz: in std_logic;
    btn_south: in std_logic;
    btn_north: in std_logic;
    led: out unsigned(7 downto 0));
end entity dimmer_test;

architecture rtl of dimmer_test is
  constant system_speed: natural := 50e6;

  signal reference_clock: std_logic;
  signal clock_x_256: std_logic;
  signal clock50hz: std_logic;
  signal on_time: unsigned(7 downto 0) := (others => '0');

begin
  clock_50hz_generator: entity clock_generator
    generic map(clock_in_speed => system_speed, clock_out_speed => 50)
    port map(
      clock_in => clk_50mhz,
      clock_out => clock50hz);

  my_pll: entity pll
    generic map(multiplier => 256,
                reference_clock_frequency => 50,
                system_clock_frequency => system_speed)
    port map(
      reference_clock => clock50hz,
      system_clock => clk_50mhz,
      clock_out => clock_x_256);

  my_dimmer: entity dimmer
    port map(
      clock50hz => clock50hz,
      clock_x_256 => clock_x_256,
      on_time => on_time,
      lamp => led(0));

  update_on_time: process(clock50hz)
  begin
    if clock50hz'event and clock50hz = '1' then
      if btn_south = '1' then
        on_time <= on_time - 1;
      end if;
      if btn_north = '1' then
        on_time <= on_time + 1;
      end if;
    end if;
  end process;
  
  led(1) <= clock50hz;
  led(2) <= clock_x_256;
  led(3) <= clk_50mhz;
  led(4) <= btn_south;
  led(5) <= btn_north;
  led(6) <= '0';
  led(7) <= '1';

end architecture rtl;


-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 105721
Subject: Re: Issues w/ 8 lane Aurora sample design
From: "billu" <bkamakot@gmail.com>
Date: 29 Jul 2006 14:28:32 -0700
Links: << >>  << T >>  << A >>
Yeah, definitely changed that.

I changed the settings to ML310 board (XC2VP30-FF896) to see if I can
find any cues to the problem. I changed phase align module and clock
pins in the ucf file and the compilation goes through fine. I cant
really find any board specific settings/properties in the code

Thanks,
Billu

Falk Brunner wrote:
> billu schrieb:
> > Just checked. I think they are ok ... 4 MGTs on the top use
> > TOP_BREF_CLK (pins B14 and C14) and 4 MGTs on the bottom row use
> > BOTTOM_BREF_CLK2 (pins AE13 and AD13)
> >
> > The same code works for a ML310 board, so I'm guessing there some
> > specific board related issue.
> >
> > Any tips?
>
> Did you select the right device and packages in the project settings?
> 
> Regards
> Falk


Article: 105722
Subject: Re: Issues w/ 8 lane Aurora sample design
From: Duane Clark <junkmail@junkmail.com>
Date: Sat, 29 Jul 2006 22:07:13 GMT
Links: << >>  << T >>  << A >>
billu wrote:
> Yeah, definitely changed that.
> 
> I changed the settings to ML310 board (XC2VP30-FF896) to see if I can
> find any cues to the problem. I changed phase align module and clock
> pins in the ucf file and the compilation goes through fine. I cant
> really find any board specific settings/properties in the code

Several things change in the source when you select a different clock 
source, at least when using the GT_CUSTOM core and Aurora2.3, assuming 
that is what the 8 lane sample uses.

The input clock signal itself needs to be tied to the the right input to 
GT_CUSTOM; that is one of the 4 B/REFCLK/2 pins.

The input REFCLKSEL needs to reflect the selection. It is '1' for 
B/REFCLK2 and '0' for B/REFCLK.

The generic (in VHDL) REF_CLK_V_SEL is 1 for REFCLK/2 and 0 for BREFCLK/2.

Article: 105723
Subject: Re: chipscope opb monitor
From: sunwei388@gmail.com
Date: 30 Jul 2006 04:53:42 -0700
Links: << >>  << T >>  << A >>

Frank van Eijkelenburg wrote:
> sunwei388@gmail.com wrote:
> > Siva Velusamy wrote:
> >
> >>Check your trigger conditions. In the trigger window, apart from
> >>specifying the value for each trigger, you also have to mention exactly
> >>which trigger condition (or a boolean combination of conditions) needs
> >>to be enabled.
> >>
> >>/S
> >>
> >>Frank van Eijkelenburg wrote:
> >>
> >>>I try to use the opb/iba unit of chipscope to monitor the opb bus within
> >>>a simple edk design. I took the chipscope lab example as start point. I
> >>>am able to see the OPB signals in chipscope, but I can not set a trigger
> >>>point. For example, I want to trigger at a certain address 0xFFFFXXXX.
> >>>If I wait for the triggercondition, the behaviour is the same if no
> >>>condition is set (like the immediate trigger button is clicked). Another
> >>>problem is: I don't see assembly or c-source code in the listing window.
> >>>Do I have to tell chipscope where it can find sources? What could be wrong?
> >>>
> >>>In the lab example there are three control ports instantiated at the
> >>>ICON unit while only two ports are connected. I have two control ports
> >>>instantiated and connected, because ISE failed at the unconnected
> >>>control port (in the map phase).
> >>>
> >>>Any ideas?
> >>>Frank
> >
> >
> > Hello Frank, Siva,
> >
> > I am also working on chipscope but it doesn't work. The error message
> > is very strange and I suppose it is an assertion error. I use EDK8.1
> > SP2, ISE8.1 SP3 and Chipscope 8.1SP3. Can you tell me what is your
> > configuration? Thanks a lot.
> >
> > Sunwei
> >
>
>
> EDK8.1.1, ISE8.1.3, ChipScope8.1.3
>
> I don't have an error message (if I remove one control port from the ICON unit,
> but triggering doesn't work and no assembly code is shown in the listing window.
>
> Frank

Hi Frank,

Thank you for your information. Maybe I need to reinstall the windows
on my computer...

Sunwei


Article: 105724
Subject: Re: Can I get 840HZ from a Xilinx Spartan-3's DCM? Phase locked?
From: "Nevo" <nevo_n@hotmail.com>
Date: Sun, 30 Jul 2006 13:34:12 GMT
Links: << >>  << T >>  << A >>
You're right; I didn't design a counter. I should have realized that I can't 
get away with imprecise language use on a technical discussion group!  I 
did, in fact, implement a 14-bit wide PWM output (essentially using a shift 
register where the incoming bit is always high.)

Thank you for the reference to the previous thread; I'll go dig it up!

-Nevo

>
> Hi Nevo -
>
> A 14-bit counter does not cycle every 14 clock cycles. It rolls over every 
> 2^14 clock cycles. It really sounds like you want a 4-bit counter counting 
> modulus 14 and driving 14 PWM outputs (plus your always-on and always-off 
> outputs). I didn't look at XAPP462 so I don't know what you're referring 
> to there, but if you need to multiply the mains frequency to generate a 
> clock, see the recent thread with the subject line "2KHz clock signal from 
> 50Hz main frequency with ADPLL".
>
> Rob
> 





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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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