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 69300

Article: 69300
Subject: Re: Altera SoPC builder command line system generator
From: kempaj@yahoo.com (Jesse Kempa)
Date: 5 May 2004 10:00:33 -0700
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp6@gustad.com> wrote in message news:<878yg7j151.fsf@zener.home.gustad.com>...
> According to "Reference Manual SOPC Builder PTF File":
> 
> "The System Generator Program can also be run from the command-line
> independent from the GUI. When the System Generator Program runs, it
> must read system design data from a PTF file. The name of the PTF file
> is given as a command line argument to the System Generator Program."
> 
> But how do I run the system generator from the command line?
> 
> The GUI appears to buld a script called SYSTEM_generation_script, but
> this seem to use an arguement ($1) which I can't seem to guess since I
> will get an malformed argument error in wiz_utils.pm later.
> 
> 
> Petter


Hi Petter,

This is a back-end feature of SOPC Builder (as nearly all of our
Nios/SOPC-related tools are currently command-line based) and as its
not visible to the customer ordinarily. As such we don't document it
beyond what you saw in the PTF doc (which is pretty close to an
internal engineering doc as far as our documentation goes).

That said, to generate your system from the command line, try this
from the Nios SDK (Bash) shell:

1. Switch to the directory where your Quartus project/SOPC Builder
design files are.
2. Type: sopc_builder <name of your .ptf file> --generate=1

The above assumes that you have a correctly formatted .ptf file ready
to go.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 69301
Subject: Re: chipscope nuance question?
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Wed, 5 May 2004 13:02:17 -0400 (EDT)
Links: << >>  << T >>  << A >>
Syms,
Thanks for your help.  Looks like I checked a flag to flatten the hiearchy
in order to try to make the design run faster.


thanks

Matt

On Wed, 5 May 2004, Symon wrote:

> Matthew,
> Sounds like you've flattened the hierarchy somehow. Check the options for
> the processes in Navigator. Or maybe your synthesis tool.
> Chipscope is a wonderful thing. I haven't used a logic analyser for years.
> And as the parts get faster, so does Chipscope. I use it to debug my home
> brew soft processor. You can export the analysis results and I run a Perl
> script to view the disassembly. Xilinx should do an integrated version for
> MicroBlaze and PowerPC.
> Cheers, Syms.
>
>
>

Article: 69302
Subject: Re: XST, Virtex2-Pro, odd PAR counter timing failure
From: Ray Andraka <ray@andraka.com>
Date: Wed, 05 May 2004 13:16:47 -0400
Links: << >>  << T >>  << A >>
Well, with the structure the Virtex CLBs, a loadable counter implemented
in one level of logic has the carry chain after the mux.  The timing
analysis does not take into account logic state, only combinatorial
paths.  In the case of the loadable counter, it sees a path out of the LUT
and up the carry chain.  Normally, the loadable counter uses the mult_and
to gate off the DI input of the mux_carry when the counter is being loaded
so that a carry does not propagate, but the timing analyzer has no way of
knowing this without your help.  You can either do what you can to reduce
the delay on the load path so it meets timing without regard to false
paths, or you can declare this as a false path.  My preference is to try
to make it pass without declaring false paths because of the danger of
inadvertently marking a valid path as false.




John Providenza wrote:

> I'm using XST for synthesis and I'm seeing an odd timing failure
> from PAR with a 19 bit counter.  The counter code is:
>
>   reg     [19:1]                  rd_addr;        // read port
>   wire    [19:1]                  rd_addr_preload;
>
>   // handle ram address counter
>   assign rd_addr_preload = (repeat_done) ? next_wave_addr :
> cur_wave_addr ;
>   always @(posedge clk_mem)
>     if (next_instr)
>         rd_addr         <= rd_addr_preload ;
>     else if (rd_req_i)
>         rd_addr         <= rd_addr + 1'b1;
>
> The signal "next_wave_addr" comes from the output of a block ram and
> is used
> to broadside load the counter.  Also note that "cur_wave_addr" could
> load
> the counter, but it's not in the critical path.
>
> For some reason, PAR traces "next_wave_addr" though the carry chain as
> a critical path.  This seems wrong. I'm scheptical that bit 4 of the
> broadside load data should ripple into bit 18 of the counter.
>
> Here's the PAR timing info:
>
> Slack:                  -0.008ns
>   Source:               Mram_program_inst_ramb_21.B (RAM)
>   Destination:          rd_addr_73 (FF)
>   Requirement:          5.999ns
>   Data Path Delay:      5.894ns (Levels of Logic = 9)
>   Clock Path Skew:      -0.113ns
>   Source Clock:         clk_mem rising at 1.172ns
>   Destination Clock:    clk_mem rising at 7.171ns
>   Clock Uncertainty:    0.000ns
>
>   Data Path: Mram_program_inst_ramb_21.B to upatgen/rd_addr_73
>     Location             Delay type         Delay(ns)  Physical
> Resource
>                                                        Logical
> Resource(s)
>     -------------------------------------------------
> -------------------
>     RAMB16_X5Y6.DOB1     Tbcko                 1.500
> Mram_program_inst_ramb_21
>
> Mram_program_inst_ramb_21.B
>     SLICE_X36Y49.F2      net (fanout=2)        1.711   seq_rd_data<77>
>     SLICE_X36Y49.X       Tilo                  0.288
> rd_addr_preload<4>
>
> Mmux_rd_addr_preload_Result<3>1
>     SLICE_X34Y48.F3      net (fanout=1)        0.262
> rd_addr_preload<4>
>     SLICE_X34Y48.COUT    Topcyf                0.744   rd_addr<4>
>
> rd_addr_inst_lut3_911
>
> rd_addr_inst_cy_125
>
> rd_addr_inst_cy_126
>     SLICE_X34Y49.CIN     net (fanout=1)        0.000
> rd_addr_inst_cy_126
>     SLICE_X34Y49.COUT    Tbyp                  0.083   rd_addr<6>
>
> rd_addr_inst_cy_127
>
> rd_addr_inst_cy_128
>     SLICE_X34Y50.CIN     net (fanout=1)        0.000
> rd_addr_inst_cy_128
>     SLICE_X34Y50.COUT    Tbyp                  0.083   rd_addr<8>
>
> rd_addr_inst_cy_129
>
> rd_addr_inst_cy_130
>     SLICE_X34Y51.CIN     net (fanout=1)        0.000
> rd_addr_inst_cy_130
>     SLICE_X34Y51.COUT    Tbyp                  0.083   rd_addr<10>
>
> rd_addr_inst_cy_131
>
> rd_addr_inst_cy_132
>     SLICE_X34Y52.CIN     net (fanout=1)        0.000
> rd_addr_inst_cy_132
>     SLICE_X34Y52.COUT    Tbyp                  0.083   rd_addr<12>
>
> rd_addr_inst_cy_133
>
> rd_addr_inst_cy_134
>     SLICE_X34Y53.CIN     net (fanout=1)        0.000
> rd_addr_inst_cy_134
>     SLICE_X34Y53.COUT    Tbyp                  0.083   rd_addr<14>
>
> rd_addr_inst_cy_135
>
> rd_addr_inst_cy_136
>     SLICE_X34Y54.CIN     net (fanout=1)        0.000
> rd_addr_inst_cy_136
>     SLICE_X34Y54.COUT    Tbyp                  0.083   rd_addr<16>
>
> rd_addr_inst_cy_137
>
> rd_addr_inst_cy_138
>     SLICE_X34Y55.CIN     net (fanout=1)        0.000
> rd_addr_inst_cy_138
>     SLICE_X34Y55.Y       Tciny                 0.891   rd_addr<18>
>
> rd_addr_inst_cy_139
>
> rd_addr_inst_sum_135
>     SLICE_X34Y55.DY      net (fanout=1)        0.000
> rd_addr_inst_sum_135
>     SLICE_X34Y55.CLK     Tdyck                 0.000   rd_addr<18>
>                                                        rd_addr_73
>     -------------------------------------------------
> ---------------------------
>     Total                           5.894ns (3.921ns logic, 1.973ns
> route)
>                                             (66.5% logic, 33.5% route)
>
> Any ideas?
>
> Thanks!
>
> John Providenza

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 69303
Subject: Re: XST, Virtex2-Pro, odd PAR counter timing failure
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 5 May 2004 11:04:54 -0700
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote in message
news:4099217F.9E954847@andraka.com...
>  My preference is to try
> to make it pass without declaring false paths because of the danger of
> inadvertently marking a valid path as false.
>
Indeed, be careful with declaring false paths
I noticed the clock skew was quite high(!) at 113ps. Does the carry chain
straddle different bits of the clock tree? You could try locking it down to
reduce the skew. You only need 8ps! Or, you could tell the timing analyser
your worst case temperature and power supply voltage to get back the 8ps.
good luck, Syms.



Article: 69304
Subject: Re: Connecting a crystal to a Cyclone or Max PLD
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 05 May 2004 11:52:49 -0700
Links: << >>  << T >>  << A >>
For a basic tutorial, on xtal oscillators, see

http://www.maxim-ic.com/appnotes.cfm/appnote_number/1017/ln/en

Peter Alfke

> From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
> Organization: Comcast Online
> Newsgroups: comp.arch.fpga
> Date: Wed, 05 May 2004 00:38:34 GMT
> Subject: Re: Connecting a crystal to a Cyclone or Max PLD
> 
> Peter Alfke wrote:
> 
>> Every xtal has parallel as well as series resonance. These two frequencies
>> are very close together, and the typical Colpitts oscillator actually
>> oscillates at a frequency in-between.
>> For most typical low-precision applications, the difference between parallel
>> and series resonance is irrelevant for the user. The crystal just picks a
>> point in-between.
> 
> Maybe not close enough if you are building a clock or frequency
> counter, but probably close enough for a CPU clock, I agree.
> 
> I agree that the frequencies are close.  Different oscillator circuits
> work differently, and I wasn't sure which your description was about.
> 
> Also, some crystals are designed to run at a higher odd harmonic of
> the fundamental, which complicates things a little.
> 
> I once knew the difference between the two types of oscillators, but
> I don't remember it now.
> 
> -- glen
> 


Article: 69305
Subject: costal loop question
From: daita@eng.usf.edu (viswanath)
Date: 5 May 2004 12:35:14 -0700
Links: << >>  << T >>  << A >>
Hi,
I have come across a lot of literature saying that costas loop is used
for phase error correction. I had few questions regarding that. After
multiplying and generating a difference signal either cos(phi) or
sin(phi) where phi is the phase difference between the incoming and
the locally generated signals, how is this translated to an angle
which can be given as an input to the VCO??
The output of the carrier discriminator which can be a multiplier is
sin(2*phi). I wanted to know what the loop filter does that converts
this value to an appropriate value as an input to the VCO.
If we consider another discriminator such as arctan then we directly
can get a phase difference angle as the input to the VCO. However what
is the use of a loop filter in this case??
Are there any higher frequency terms that need to be filtered out?
Could you please reply to my questions?
I would greatly appreciate your response.
Thanking You,
Viswanath

Article: 69306
Subject: Re: How to drive record fields from procedure AND testbench?
From: Jim Lewis <Jim@SynthWorks.com>
Date: Wed, 05 May 2004 13:01:38 -0700
Links: << >>  << T >>  << A >>
Joe,
Initialize the record element to 'Z'.

Step 1 declare the following constant after the place in
the package where you declare "rec":

     constant INIT_REC : rec := ('Z', 'Z', 'Z', (others => 'Z') ;


Step 2 initialize the signal declaration (in the testbench):
     signal busRec : rec := INIT_REC ;


This is not in books, however, it is in our testbench classes:
     http://www.synthworks.com/vhdl_testbench_verification.htm

In the class we also use a similar technique for our transaction
based models.  Some details are in the testbench paper at:
     http://www.synthworks.com/papers

Cheers,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


> Hi folks,
> 
> I am having a problem that is beyound my present VHDL capabilities. 
> 
> I am trying to model a bus in a testbench using the following
> (incomplete) record:
> 
> type rec is record
>   rd, wr, waitreq : std_logic;
>   writedata       : std_logic_vector(31 downto 0);
> end record;
> 
> (I left a bunch out for brevity).
> 
> - rd, wr, and writedata are driven by the master of the bus.
> - waitreq is driven by the slave, indicating when it can't immediately
> satisfy a master request.
> 
> I then have some useful functions having prototypes:
> 
>   procedure InitBus( signal busRec: inout rec );
>   procedure WriteValue( signal busRec: inout rec; 
>                         address: integer; 
>                         value: integer );
> 
> And in my code I hook things up:
> 
>   architecture ...
>     signal busRec : rec;
>     ...
>   begin
>     DUT_inst : DUT port map ( wr=>wr, rd=>rd, 
>                  waitreq=>waitreq, readdata=>readdata,
>                  ... );
> 
>     wr <= rec.wr;
>     rd <= rec.rd;
>     writedata <= rec.writedata;
>     rec.waitreq  <= waitreq;
> 
>     InitBus( rec );
> 
>   end;
> 
> This setup causes an error, presumably because some records are driven
> from the procedure, and others from the DUT.
> 
> How do the "professionals" create and use a record that has some
> fields driving one way, and others driving the other?
> 
> I've successfully used this arrangement before, but I managed to have
> all the fields of the record driven from the procedures. In this case
> I now have a waitreq, which is an integral part of the bus model,
> driven by the DUT . Is it possible to bring this signal into the
> procedures using a single record? Or do things have to get messy?
> 
> A further question is when I have a birectional data bus (driven by
> the master during writes, driven by the DUT during reads). Example:
> 
>   begin
>     DUT_inst: DUT port map ( data => bidir_data ... );
>     rec.bidir_data  <= bidir_data;
>   end;
> 
> Can I even manage bidirection data buses with the record approach?
> 
> Can someone suggest further reading on how to do this stuff? An
> admittedly cursory Google search brought up all kinds of stuff on
> records, but nothing that I could relate to my problem. Obviously,
> though, this sort of thing must be done all the time in testbenches,
> but I somehow haven't come across. I certainly don't want to manually
> write out bus transaction without procedures.
> 
> Joe


Article: 69307
Subject: Re: frequency multiplication
From: Walter Dvorak <use-reply-to@gruebel.invalid>
Date: Wed, 05 May 2004 15:01:58 -0500
Links: << >>  << T >>  << A >>
Jim <Jim@eab.nl> wrote:
> Therefor i'd like to implement a 'dpll' in a cpld, that can multiply 48KHz
> to 6144KHz, or is there perhaps another way?

	if it is for digital audio: Use an external 6.144MHz VCXO and
a portion of a CPLD for the clock divider and the XOR between
clock divider output and your 48kHz word clock input. This solution 
has low jitter and give you a stable 6.144MHz. Useable for audio-DACs, 
AES3-encoders, etc... 

	And, dont forget a simple low pass filter (10k, 47n) between 
the CPLD output pin and the voltage-control-XO input. 

WD
-- 

Article: 69308
Subject: Re: How to drive record fields from procedure AND testbench?
From: mike_treseler@comcast.net (Mike Treseler)
Date: 5 May 2004 13:22:22 -0700
Links: << >>  << T >>  << A >>
Joe Vanderwall wrote :
> I am trying to model a bus in a testbench using the following
> (incomplete) record:
> 
> type rec is record
>   rd, wr, waitreq : std_logic;
>   writedata       : std_logic_vector(31 downto 0);
> end record;
>
> How do the "professionals" create and use a record that has some
> fields driving one way, and others driving the other?

No easy answers.
The record direction problem is discussed in this thread:
   http://groups.google.com/groups?q=gaggle.DSPaddr

The signal scope problem is discussed in this thread:
   http://groups.google.com/groups?q=vhdl+recap+clumsy

   -- Mike Treseler

Article: 69309
Subject: V2p block ram clock -> Q delay help
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Wed, 5 May 2004 18:50:30 -0400 (EDT)
Links: << >>  << T >>  << A >>
Hi all,
I have a long combinational path in my fpga design and I am looking for
ways to reduce the path.  one of the biggest contributors is the clock to
Q delay from memory on some of the inputs to the path.  The
memory(blockram) is currently very wide and not deep.
Is there a way to optimize the size or any other paramaters to decrease
the clock to Q time?

Thanks

Matt

Article: 69310
Subject: bitgen progarm in ISE
From: fhleung <fhleung@hotmail.com>
Date: Wed, 5 May 2004 16:40:46 -0700
Links: << >>  << T >>  << A >>
Hi all, 
I am a novice user of ISE and seeking for help. 

ISE can generate programming files for FPGA. Formats like .bit .bin and .rbt 

Application note XAPP502 can help a bit but I still got confusion on above the files types. 

Which of the file type is finally downloaded to FPGA? 

Which type can be loaded and processed by microcontroller? 

Thank you in advance. 

fhleung 



Article: 69311
Subject: Re: V2p block ram clock -> Q delay help
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 05 May 2004 17:01:14 -0700
Links: << >>  << T >>  << A >>
Pipelining is the most obvious and most popular way to reduce long delays.
When it can be used, it is great...
Peter Alfke

> From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
> Organization: Carnegie Mellon, Pittsburgh, PA
> Newsgroups: comp.arch.fpga
> Date: Wed, 5 May 2004 18:50:30 -0400 (EDT)
> Subject: V2p block ram clock -> Q delay help
> 
> Hi all,
> I have a long combinational path in my fpga design and I am looking for
> ways to reduce the path.  one of the biggest contributors is the clock to
> Q delay from memory on some of the inputs to the path.  The
> memory(blockram) is currently very wide and not deep.
> Is there a way to optimize the size or any other paramaters to decrease
> the clock to Q time?
> 
> Thanks
> 
> Matt


Article: 69312
Subject: Re: V2p block ram clock -> Q delay help
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Wed, 5 May 2004 20:24:41 -0400 (EDT)
Links: << >>  << T >>  << A >>
Unfortunately that can not be implemented.  I was hoping for something
specific to bram clock-> Q delay.


Matt
On Wed, 5 May 2004, Peter Alfke wrote:

> Pipelining is the most obvious and most popular way to reduce long delays.
> When it can be used, it is great...
> Peter Alfke
>
> > From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
> > Organization: Carnegie Mellon, Pittsburgh, PA
> > Newsgroups: comp.arch.fpga
> > Date: Wed, 5 May 2004 18:50:30 -0400 (EDT)
> > Subject: V2p block ram clock -> Q delay help
> >
> > Hi all,
> > I have a long combinational path in my fpga design and I am looking for
> > ways to reduce the path.  one of the biggest contributors is the clock to
> > Q delay from memory on some of the inputs to the path.  The
> > memory(blockram) is currently very wide and not deep.
> > Is there a way to optimize the size or any other paramaters to decrease
> > the clock to Q time?
> >
> > Thanks
> >
> > Matt
>
>

Article: 69313
Subject: Re: How to drive record fields from procedure AND testbench?
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 5 May 2004 19:32:29 -0700
Links: << >>  << T >>  << A >>
Hi Mike,

Thanks for the reply. I must be on the right track, because it looks
like I have been doing what you suggested in
http://groups.google.com/groups?q=gaggle.DSPaddr. However, the InitBus
call causes compile errors in my design. If I comment out the InitBus
call, it compiles fine. (Note that I'm not tackling the inout
(tristate) problem at the moment, just the problem of record fields
that are either driven from procedures or from the DUT.)

In the thread you cited, no procedure calls are shown, so I'm
wondering if this is not possible? Why exactly does my procedure call
cause problems with resolution?

I'm wondering if the VHDL standard dictates to not look inside the
procedure to check if there really would be a resolution problem. My
evidence for this is that even if my procedure contains nothing at
all, it still will not compile. When the procedure is empty, in my
mind it should be the the same as not having the procedure present at
all (a case which compiles fine). Strange. Is the prototype for the
InitBus procedure correct for a record that is driven in and out of
the procedure?

Another way for the compile to succeed is to remove the driving of
rec.waitreq, so the problems are hinging on the fact that different
fields being driven from different sources.

  prototype:  

    procedure InitBus( signal busRec: inout rec );

  architecture:

    -- connections
    wr <= rec.wr;
    rd <= rec.rd;
    writedata <= rec.writedata;
    rec.waitreq  <= waitreq;

    -- this line will cause compile to fail:
    InitBus( rec );

Joe

> No easy answers.
> The record direction problem is discussed in this thread:
>    http://groups.google.com/groups?q=gaggle.DSPaddr
> 
> The signal scope problem is discussed in this thread:
>    http://groups.google.com/groups?q=vhdl+recap+clumsy
> 
>    -- Mike Treseler

Article: 69314
Subject: Re: bitgen progarm in ISE
From: "Jim Wu" <NOSPAM@NOSPAM.com>
Date: Thu, 06 May 2004 02:59:09 GMT
Links: << >>  << T >>  << A >>
> ISE can generate programming files for FPGA. Formats like .bit .bin and
.rbt
> Application note XAPP502 can help a bit but I still got confusion on above
the files types.

> Which of the file type is finally downloaded to FPGA?

.bit file

> Which type can be loaded and processed by microcontroller?

They should all work if you know the file format. You can choose one that
works best with your hardware.

HTH,
Jim
jimwu88NOOOSPAM@yahoo.com
http://www.geocities.com/jimwu88/chips



Article: 69315
Subject: Re: Altera SoPC builder command line system generator
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 06 May 2004 07:30:56 +0200
Links: << >>  << T >>  << A >>
kempaj@yahoo.com (Jesse Kempa) writes:

> That said, to generate your system from the command line, try this
> from the Nios SDK (Bash) shell:
> 
> 1. Switch to the directory where your Quartus project/SOPC Builder
> design files are.
> 2. Type: sopc_builder <name of your .ptf file> --generate=1
> 
> The above assumes that you have a correctly formatted .ptf file ready
> to go.

Thank you for your advice. I think I found the problem. I was thinking
that SYSTEM_generation_script was self contained. It appears that
there is a problem with the handling or interpretation of the argument
--sopc_perl. It seems like the --sopc_perl in the
SYSTEM_generation_script does not do very much. However, If I set the
environment variable SOPC_PERL to point at the supplied perl version
($QUARTUS_HOME/linux/perl561) it works!

I like the way the SOPC builder will build a script
(SYSTEM_generation_script) which will build the system just like it
was done in the GUI. However, it appears that this script isn't
completely standalone. But as I said, if I set SOPC_PERL it will work.


Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 69316
Subject: Re: bitgen progarm in ISE
From: fhleung <fhleung@hotmail.com>
Date: Thu, 6 May 2004 00:58:44 -0700
Links: << >>  << T >>  << A >>
Which of the file type is finally downloaded to FPGA?
 .bit is the binary file that contains header information 
that should not be downloaded to FPGA-- from application notes XAPP502

Article: 69317
Subject: Re: bitgen progarm in ISE
From: Sean Durkin <smd@despammed.com>
Date: Thu, 06 May 2004 10:31:38 +0200
Links: << >>  << T >>  << A >>
fhleung wrote:

> Which of the file type is finally downloaded to FPGA?
> .bit is the binary file that contains header information that should not be 
> downloaded to FPGA-- from application notes XAPP502
It all depends on what you want to use for downloading. If you use 
iMPACT or Chipscope, then you use the .bit. iMPACT and Chipscope can use 
the header information to make sure you're not downloading a bitstream 
for a different architecture by mistake and such.

If you want to use a microcontroller to program the FPGA directly via 
SelectMAP, then you can either strip the header from the bit, or you 
could use the .RBT... The .RBT contains the bitstream in 1's and 0's in 
a text file, that should be easy enough to process via software. But of 
course the RBT is much bigger.

As a third, and probably preferred option for you: in ISE in the 
"Generate Programming File"-section there's also an option to generate a 
"Binary configuration file", that does not contain the header. If you 
call "bitgen" on the command line, you'd use "g Binary:Yes" as 
parameters. This gives you a .BIN-file, which you can send to the FPGA 
directly.

cu,
Sean

Article: 69318
Subject: Re: Max7000s: how to use the enable of the dffe flip-flop?
From: javodv@yahoo.es (javid)
Date: 6 May 2004 02:34:00 -0700
Links: << >>  << T >>  << A >>
Thanks a lot for the comments Marc,

But my main question is that when I look at the RTL View of the vhdl
file I see that uses a D flip-flops and feedbacks the outputs of these
to the input of a mux that select with LOAD if the input to the
Dflip-flops are the previous output (A_O) or the present input (V_I).
I will use the Altera CPLD Max7000s that seems to have a D flip-flop
with enable input and I would like that the LOAD input would go to the
Enable input of the flip-flops instead of the feedback + mux solution
and leaving unconnected the enable input of the flip-flop. How to do
this?

Thanks a lot and best regards,

Javi


Marc Randolph <mrand@my-deja.com> wrote in message news:<UL6dndL0hKNIRwXdRVn-
sA@comcast.com>...
> javid wrote:
> > Dear all,
> > 
> > I would like to register an address bus with the rising edge of the
> > clk and if the LOAD is '1'. Below is my VHDL code.
> > 
> > The problem is that when I analyse and elaborate with QII and see the
> > RTL view I see a mux that choose A_I or A_O with LOAD and the the
> > output of this mux goes to a dffe flip-flops (the output of this
> > flip-flops are feedback to the input of the mux). I would like to use
> > the enable input of the dffe flip-flops instead of the mux with the
> > LOAD. How to do this? is the RTL view related with what finally will
> > be placed and routed?.
> 
> Oh my that's alot of typing (and very prone to typos).  I believe the 
> problem is that you have more than one controlling if statement within 
> the process (in this case, more than one rising edge statement).  But 
> the reality of the matter is that you only need one!
> 
> 
> ADR_REG: process ( CLK_I )
> begin
> 
>     if( rising_edge(CLK_I) ) then
>        if( LOAD = '1' )
>           A_O( 2) <= A_I( 2);
>        end if;
>        if( LOAD = '1' )
>           A_O( 3) <= A_I( 3);
>        end if;
> ....etc....
>        if( LOAD = '1' )
>           A_O(18) <= A_I(18);
>        end if;
>     end if;
> 
> end process ADR_REG;
> 
> But you'll notice the load's are all the same... so why not:
> 
> ADR_REG: process ( CLK_I )
> begin
> 
>     if( rising_edge(CLK_I) ) then
>        if( LOAD = '1' )
>           A_O( 2) <= A_I( 2);
>           A_O( 3) <= A_I( 3);
> ....etc....
>           A_O(18) <= A_I(18);
>        end if;
>     end if;
> 
> end process ADR_REG;
> 
> 
> But that's still WAY too much error-prone typing!  In reality, we should 
> be using the vector form:
> 
> 
> ADR_REG: process ( CLK_I )
> begin
> 
>     if( rising_edge(CLK_I) ) then
>        if( LOAD = '1' )
>           A_O(18 downto 2) <= A_I(18 downto 2);
>        end if;
>     end if;
> 
> end process ADR_REG;
> 
> 
> If you had a real reason to not use the vector form above, you could use 
> a generate statement (this would allow you to optionally have a 
> different clock enable for each bit, if you needed that for some reason):
> 
> adr_gen : for i in 2 to 18 GENERATE
> 
> ADR_REG: process ( CLK_I )
> begin
> 
>     if( rising_edge(CLK_I) ) then
>        if( LOAD = '1' )
>           A_O(i) <= A_I(i);
>        end if;
>     end if;
> 
> end process ADR_REG;
> 
> end generate;
> 
> 
> 
> Good luck,
> 
>     Marc
> 
> 
> 
> > Thanks a lot and best regards,
> > 
> > Javi
> > 
> > 
> > entity DIR_LATCH is
> >   
> >   port(  A_O:   out std_logic_vector ( 18 downto 2 );  
> >          LOAD:   in  std_logic;  
> >          CLK_I:   in  std_logic;  
> >          A_I:    in  std_logic_vector ( 18 downto 2)  
> >       );
> > 		
> > end entity DIR_LATCH;
> > 
> > 
> > -------------------------------------------------------------------------------
> > -- Definicion de la Arquitectura
> > -------------------------------------------------------------------------------
> > 
> > architecture DIR_LATCH_A1 of DIR_LATCH is
> > 
> > begin
> > 
> >   -----------------------------------------------------------------------------
> >   -- Definicion de la Arquitectura
> >   -----------------------------------------------------------------------------
> > 
> >   ADR_REG: process ( CLK_I )
> >   begin
> > 
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 2) <=
> > A_I( 2); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 3) <=
> > A_I( 3); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 4) <=
> > A_I( 4); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 5) <=
> > A_I( 5); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 6) <=
> > A_I( 6); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 7) <=
> > A_I( 7); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 8) <=
> > A_I( 8); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 9) <=
> > A_I( 9); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(10) <=
> > A_I(10); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(11) <=
> > A_I(11); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(12) <=
> > A_I(12); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(13) <=
> > A_I(13); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(14) <=
> > A_I(14); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(15) <=
> > A_I(15); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(16) <=
> > A_I(16); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(17) <=
> > A_I(17); end if; end if;
> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(18) <=
> > A_I(18); end if; end if;
> > 
> >   end process ADR_REG;
> > 
> > end architecture DIR_LATCH_A1;

Article: 69319
Subject: Re: bitgen progarm in ISE
From: Petter Gustad <newsmailcomp5@gustad.com>
Date: 06 May 2004 12:58:14 +0200
Links: << >>  << T >>  << A >>
Sean Durkin <smd@despammed.com> writes:

> If you want to use a microcontroller to program the FPGA directly via
> SelectMAP, then you can either strip the header from the bit, or you
> could use the .RBT... The .RBT contains the bitstream in 1's and 0's
> in a text file, that should be easy enough to process via software.
> But of course the RBT is much bigger.

Some users/tools use SVF files as a base for programming through the
JTAG port.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 69320
Subject: Re: Max7000s: how to use the enable of the dffe flip-flop?
From: Marc Randolph <mrand@my-deja.com>
Date: Thu, 06 May 2004 06:22:38 -0500
Links: << >>  << T >>  << A >>
javid wrote:
> Thanks a lot for the comments Marc,
> 
> But my main question is that when I look at the RTL View of the vhdl
> file I see that uses a D flip-flops and feedbacks the outputs of these
> to the input of a mux that select with LOAD if the input to the
> Dflip-flops are the previous output (A_O) or the present input (V_I).
> I will use the Altera CPLD Max7000s that seems to have a D flip-flop
> with enable input and I would like that the LOAD input would go to the
> Enable input of the flip-flops instead of the feedback + mux solution
> and leaving unconnected the enable input of the flip-flop. How to do
> this?

Howdy Javi,

Unless there is a very severe bug in the synthesis tools that you are 
using, you do this by using one (and _only one_) "if rising_edge(clk)" 
statement per process.  See below for examples.

    Marc


> Marc Randolph <mrand@my-deja.com> wrote in message news:<UL6dndL0hKNIRwXdRVn-
> sA@comcast.com>...
> 
>>Oh my that's alot of typing (and very prone to typos).  I believe the 
>>problem is that you have more than one controlling if statement within 
>>the process (in this case, more than one rising edge statement).  But 
>>the reality of the matter is that you only need one!
>>
>>
>>ADR_REG: process ( CLK_I )
>>begin
>>
>>    if( rising_edge(CLK_I) ) then
>>       if( LOAD = '1' )
>>          A_O( 2) <= A_I( 2);
>>       end if;
>>       if( LOAD = '1' )
>>          A_O( 3) <= A_I( 3);
>>       end if;
>>....etc....
>>       if( LOAD = '1' )
>>          A_O(18) <= A_I(18);
>>       end if;
>>    end if;
>>
>>end process ADR_REG;
>>
>>But you'll notice the load's are all the same... so why not:
>>
>>ADR_REG: process ( CLK_I )
>>begin
>>
>>    if( rising_edge(CLK_I) ) then
>>       if( LOAD = '1' )
>>          A_O( 2) <= A_I( 2);
>>          A_O( 3) <= A_I( 3);
>>....etc....
>>          A_O(18) <= A_I(18);
>>       end if;
>>    end if;
>>
>>end process ADR_REG;
>>
>>
>>But that's still WAY too much error-prone typing!  In reality, we should 
>>be using the vector form:
>>
>>
>>ADR_REG: process ( CLK_I )
>>begin
>>
>>    if( rising_edge(CLK_I) ) then
>>       if( LOAD = '1' )
>>          A_O(18 downto 2) <= A_I(18 downto 2);
>>       end if;
>>    end if;
>>
>>end process ADR_REG;
>>
>>
>>If you had a real reason to not use the vector form above, you could use 
>>a generate statement (this would allow you to optionally have a 
>>different clock enable for each bit, if you needed that for some reason):
>>
>>adr_gen : for i in 2 to 18 GENERATE
>>
>>ADR_REG: process ( CLK_I )
>>begin
>>
>>    if( rising_edge(CLK_I) ) then
>>       if( LOAD = '1' )
>>          A_O(i) <= A_I(i);
>>       end if;
>>    end if;
>>
>>end process ADR_REG;
>>
>>end generate;
>>
>>
>>    Marc
>>
>>>Thanks a lot and best regards,
>>>
>>>Javi
>>>
>>>
>>>entity DIR_LATCH is
>>>  
>>>  port(  A_O:   out std_logic_vector ( 18 downto 2 );  
>>>         LOAD:   in  std_logic;  
>>>         CLK_I:   in  std_logic;  
>>>         A_I:    in  std_logic_vector ( 18 downto 2)  
>>>      );
>>>		
>>>end entity DIR_LATCH;
>>>
>>>
>>>-------------------------------------------------------------------------------
>>>-- Definicion de la Arquitectura
>>>-------------------------------------------------------------------------------
>>>
>>>architecture DIR_LATCH_A1 of DIR_LATCH is
>>>
>>>begin
>>>
>>>  -----------------------------------------------------------------------------
>>>  -- Definicion de la Arquitectura
>>>  -----------------------------------------------------------------------------
>>>
>>>  ADR_REG: process ( CLK_I )
>>>  begin
>>>
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 2) <=
>>>A_I( 2); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 3) <=
>>>A_I( 3); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 4) <=
>>>A_I( 4); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 5) <=
>>>A_I( 5); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 6) <=
>>>A_I( 6); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 7) <=
>>>A_I( 7); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 8) <=
>>>A_I( 8); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 9) <=
>>>A_I( 9); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(10) <=
>>>A_I(10); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(11) <=
>>>A_I(11); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(12) <=
>>>A_I(12); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(13) <=
>>>A_I(13); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(14) <=
>>>A_I(14); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(15) <=
>>>A_I(15); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(16) <=
>>>A_I(16); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(17) <=
>>>A_I(17); end if; end if;
>>>    if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(18) <=
>>>A_I(18); end if; end if;
>>>
>>>  end process ADR_REG;
>>>
>>>end architecture DIR_LATCH_A1;

Article: 69321
Subject: Re: Max7000s: how to use the enable of the dffe flip-flop?
From: Luc Braeckman <luc.braeckman@pandora.be>
Date: Thu, 06 May 2004 13:47:17 GMT
Links: << >>  << T >>  << A >>
Javi,

You haven't defined your FF completely.
That's probably why you have a mux.

You should have done something like

process (clk, reset)
begin
	if reset = '1' then
		data <= (others => '0');
	elsif clk'event and clk = '1' then
		if load = '1' then
			data(18 downto 2) <= data_in (..);
		else
			data(18 downto 2) <= (others => 'Z');
		end if;
	end if;
end process;

hope this helps

On 6 May 2004 02:34:00 -0700, javodv@yahoo.es (javid) wrote:

>Thanks a lot for the comments Marc,
>
>But my main question is that when I look at the RTL View of the vhdl
>file I see that uses a D flip-flops and feedbacks the outputs of these
>to the input of a mux that select with LOAD if the input to the
>Dflip-flops are the previous output (A_O) or the present input (V_I).
>I will use the Altera CPLD Max7000s that seems to have a D flip-flop
>with enable input and I would like that the LOAD input would go to the
>Enable input of the flip-flops instead of the feedback + mux solution
>and leaving unconnected the enable input of the flip-flop. How to do
>this?
>
>Thanks a lot and best regards,
>
>Javi
>
>
>Marc Randolph <mrand@my-deja.com> wrote in message news:<UL6dndL0hKNIRwXdRVn-
>sA@comct067693ast.com>...
>> javid wrote:
>> > Dear all,
>> > 
>> > I would like to register an address bus with the rising edge of the
>> > clk and if the LOAD is '1'. Below is my VHDL code.
>> > 
>> > The problem is that when I analyse and elaborate with QII and see the
>> > RTL view I see a mux that choose A_I or A_O with LOAD and the the
>> > output of this mux goes to a dffe flip-flops (the output of this
>> > flip-flops are feedback to the input of the mux). I would like to use
>> > the enable input of the dffe flip-flops instead of the mux with the
>> > LOAD. How to do this? is the RTL view related with what finally will
>> > be placed and routed?.
>> 
>> Oh my that's alot of typing (and very prone to typos).  I believe the 
>> problem is that you have more than one controlling if statement within 
>> the process (in this case, more than one rising edge statement).  But 
>> the reality of the matter is that you only need one!
>> 
>> 
>> ADR_REG: process ( CLK_I )
>> begin
>> 
>>     if( rising_edge(CLK_I) ) then
>>        if( LOAD = '1' )
>>           A_O( 2) <= A_I( 2);
>>        end if;
>>        if( LOAD = '1' )
>>           A_O( 3) <= A_I( 3);
>>        end if;
>> ....etc....
>>        if( LOAD = '1' )
>>           A_O(18) <= A_I(18);
>>        end if;
>>     end if;
>> 
>> end process ADR_REG;
>> 
>> But you'll notice the load's are all the same... so why not:
>> 
>> ADR_REG: process ( CLK_I )
>> begin
>> 
>>     if( rising_edge(CLK_I) ) then
>>        if( LOAD = '1' )
>>           A_O( 2) <= A_I( 2);
>>           A_O( 3) <= A_I( 3);
>> ....etc....
>>           A_O(18) <= A_I(18);
>>        end if;
>>     end if;
>> 
>> end process ADR_REG;
>> 
>> 
>> But that's still WAY too much error-prone typing!  In reality, we should 
>> be using the vector form:
>> 
>> 
>> ADR_REG: process ( CLK_I )
>> begin
>> 
>>     if( rising_edge(CLK_I) ) then
>>        if( LOAD = '1' )
>>           A_O(18 downto 2) <= A_I(18 downto 2);
>>        end if;
>>     end if;
>> 
>> end process ADR_REG;
>> 
>> 
>> If you had a real reason to not use the vector form above, you could use 
>> a generate statement (this would allow you to optionally have a 
>> different clock enable for each bit, if you needed that for some reason):
>> 
>> adr_gen : for i in 2 to 18 GENERATE
>> 
>> ADR_REG: process ( CLK_I )
>> begin
>> 
>>     if( rising_edge(CLK_I) ) then
>>        if( LOAD = '1' )
>>           A_O(i) <= A_I(i);
>>        end if;
>>     end if;
>> 
>> end process ADR_REG;
>> 
>> end generate;
>> 
>> 
>> 
>> Good luck,
>> 
>>     Marc
>> 
>> 
>> 
>> > Thanks a lot and best regards,
>> > 
>> > Javi
>> > 
>> > 
>> > entity DIR_LATCH is
>> >   
>> >   port(  A_O:   out std_logic_vector ( 18 downto 2 );  
>> >          LOAD:   in  std_logic;  
>> >          CLK_I:   in  std_logic;  
>> >          A_I:    in  std_logic_vector ( 18 downto 2)  
>> >       );
>> > 		
>> > end entity DIR_LATCH;
>> > 
>> > 
>> > -------------------------------------------------------------------------------
>> > -- Definicion de la Arquitectura
>> > -------------------------------------------------------------------------------
>> > 
>> > architecture DIR_LATCH_A1 of DIR_LATCH is
>> > 
>> > begin
>> > 
>> >   -----------------------------------------------------------------------------
>> >   -- Definicion de la Arquitectura
>> >   -----------------------------------------------------------------------------
>> > 
>> >   ADR_REG: process ( CLK_I )
>> >   begin
>> > 
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 2) <=
>> > A_I( 2); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 3) <=
>> > A_I( 3); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 4) <=
>> > A_I( 4); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 5) <=
>> > A_I( 5); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 6) <=
>> > A_I( 6); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 7) <=
>> > A_I( 7); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 8) <=
>> > A_I( 8); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O( 9) <=
>> > A_I( 9); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(10) <=
>> > A_I(10); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(11) <=
>> > A_I(11); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(12) <=
>> > A_I(12); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(13) <=
>> > A_I(13); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(14) <=
>> > A_I(14); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(15) <=
>> > A_I(15); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(16) <=
>> > A_I(16); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(17) <=
>> > A_I(17); end if; end if;
>> >     if( rising_edge(CLK_I) ) then if( LOAD = '1' ) then A_O(18) <=
>> > A_I(18); end if; end if;
>> > 
>> >   end process ADR_REG;
>> > 
>> > end architecture DIR_LATCH_A1;


Article: 69322
Subject: Re: costal loop question
From: rrr@ieee.org (Rajeev)
Date: 6 May 2004 06:55:29 -0700
Links: << >>  << T >>  << A >>
daita@eng.usf.edu (viswanath) wrote in message news:<791e9679.0405051135.17e8df30@posting.google.com>...
> Hi,
> I have come across a lot of literature saying that costas loop is used
> for phase error correction. I had few questions regarding that. After

The beauty of the Costas loop is that it is a relatively simple circuit
that allows you to extract both the clock and data from a modulated
data stream eg BPSK.

> multiplying and generating a difference signal either cos(phi) or
> sin(phi) where phi is the phase difference between the incoming and
> the locally generated signals, how is this translated to an angle
> which can be given as an input to the VCO??

That's the beauty of feedback.  It is not necessary to calculate an
angle, just to nudge the VCO in the 'right' direction.  You can use
+/- cos/sin of the phase difference, the system will settle at a
'stable equilibrium' phase, with the VCO 0/90/180/270 degrees from
the incoming data.

> The output of the carrier discriminator which can be a multiplier is
> sin(2*phi). I wanted to know what the loop filter does that converts
> this value to an appropriate value as an input to the VCO.
> If we consider another discriminator such as arctan then we directly
> can get a phase difference angle as the input to the VCO. However what
> is the use of a loop filter in this case??
> Are there any higher frequency terms that need to be filtered out?

The multiplication you've mentioned above gives will give you terms
at twice the clock frequency, in addition to the low frequency term
you want.  On paper, the 2F terms are disposed of by averaging over
a clock period, but in hardware they are eliminated by the loop filter.

> Could you please reply to my questions?
> I would greatly appreciate your response.
> Thanking You,
> Viswanath

What kind of Costas loop do you wish to implement ? In what kind of
hardware ?

Good luck,
-rajeev-

Article: 69323
Subject: headers linker script
From: Tom <t_t_1232000@yahoo.com>
Date: Thu, 06 May 2004 16:24:03 +0200
Links: << >>  << T >>  << A >>
Hi, 

I read the section about headers in the gnu linker document. But it
remains a mystery to me. Why would you use headers. Why are some
sections assigned to a header and why are some sections not ?

It would help me very much if anyone could answer these questions !

Tom

Article: 69324
Subject: Re: programming the mach231
From: nate <nathan_wilson@tepidmail.com>
Date: 6 May 2004 09:53:31 -0500
Links: << >>  << T >>  << A >>
gabor@alacron.com (Gabor Szakacs) wrote in
news:8a436ba2.0405030658.15db7c85@posting.google.com: 

> nate <nathan_wilson@tepidmail.com> wrote in message
> news:<Xns94DB630BB20F7nathanwilson@209.242.86.10>... 
>> I have a bunch of free mach231 chips but I can't find any information
>> about how to program them. I have gathered from the web that they are
>> not JTAG. The datasheet does not explain how to program the chip. I
>> am planning on constructing a programmer but there is not a lot of
>> information about how to do this. The closest thing I have found is
>> some information and schematics showing how to build the expro-60.
>> Any ideas or information would be appreciated. 
>> 
>> Nathan
>> 
>> change tepid to hot to reach me by e-mail
> 
> This is a problem with most programmable chips these days.  The
> manufacturers normally supply the programming data to the major
> programmer manufacturers (Data I/O, BP, etc.) and don't bother
> to put it in the databook unless the part is in-system programmable.
> 
> If you can get the information at all, you'll do best to contact
> Lattice Semiconductor directly.
> 
> Good Luck
> 
> Gabor
> 

Lattice just says go to a third-party programmer company for any 
programming support. Does anyone work for Lattice or have a friend at 
Lattice who could get this kind of info?

Nathan



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