Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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 comArticle: 69301
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
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"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
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
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, ViswanathArticle: 69306
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: 69307Jim <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
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 TreselerArticle: 69309
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 MattArticle: 69310
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. fhleungArticle: 69311
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 > > MattArticle: 69312
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
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> 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/chipsArticle: 69315
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
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 XAPP502Article: 69317
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, SeanArticle: 69318
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
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
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: 69321Javi, 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
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
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 ! TomArticle: 69324
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:
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