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 69325

Article: 69325
Subject: Mutiple Quartus Instances?
From: "Kenneth Land" <kland1@neuralog1.com1>
Date: Thu, 6 May 2004 10:19:29 -0500
Links: << >>  << T >>  << A >>
Anyone know if there are any gotcha's with working with multiple Quartus (II
v. 4) projects on the same computer?

I'd like to work several approaches simultaneously, but not if there are
side effects - subtle or otherwise.

Thanks,
Ken



Article: 69326
Subject: Re: XST, Virtex2-Pro, odd PAR counter timing failure
From: johnp3+nospam@probo.com (John Providenza)
Date: 6 May 2004 08:30:39 -0700
Links: << >>  << T >>  << A >>
All -

Thanks for your comments on my problem.

I'm also a bit worried about using false paths, but I
think this one *might* be safe:

NET     "upatgen/*_inst_cy_*"        TPTHRU = "thru_carry";
TIMESPEC "TS_seq_rd_addr"    =
                FROM    RAMS(upatgen/seq_rd_data<*>)
                THRU    "thru_carry"
                TO      FFS (upatgen/rd_addr<*>)         10ns;

I'm a bit worried that this could be toooo agressive, is there
a way to to restrict this specifically to the COUT/CIN pins?

John P

"Symon" <symon_brewer@hotmail.com> wrote in message news:<c7bac9$21dk9$1@ID-212844.news.uni-berlin.de>...
> "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: 69327
Subject: Re: V2p block ram clock -> Q delay help
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Thu, 06 May 2004 09:46:46 -0600
Links: << >>  << T >>  << A >>


Matthew E Rosenthal wrote:
> Unfortunately that can not be implemented.  I was hoping for something
> specific to bram clock-> Q delay.


The BlockRAM CLK -> Q can only be improved by going to a faster speed 
grade.  If that is out of the question and adding latency is not an 
option then you have two choices, either look elsewhere to reduce the 
path delays or not use the BlockRAM.  You mention that you do not need 
the RAM very deep but do need it very wide.  Have you considered using 
LUT-based RAM (RAM16X1S)?  You can configure LUT-based RAM fairly easily 
in 16, 32 and 64 bit depths and will see a better CLK -> Q than in the 
BlockRAMs and on top of that, likely see better placement for wider 
buses since they are not all tied together like they are in a BlockRAM. 
   Also, LUT-RAMs have asynchronous reads so if you want to keep that 
clock cycle of latency for your reads, you can either add a register to 
the output of the RAM in the same slice and get that latency back and 
still get a  good CLK --> Q or else you can push that register deeper 
into you critical path and perhaps get a better balance of registers in 
that path and thus get much better timing.  You can configure the 
LUT-RAMs to depths deeper than 64-bits but you start to consume a lot of 
LUT resources and the trade-off is not as great.  My suggestion is if 
you can get by with 64-bits or less ore bit, might as well go to 
LUT-RAM.  If you need deeper RAMs, stay in the BlockRAM and look at 
reducing routing delays (you can try adding placement constraints, 
replicating registers/logic, higher effort levels in Map/Par, etc.) or 
logic levels for those critical paths (try harder synthesis 
constraints/options, re-coding that section of the design, etc.).

Good Luck,

--  Brian

> 
> 
> 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: 69328
Subject: Re: Max7000s: how to use the enable of the dffe flip-flop?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 6 May 2004 09:29:22 -0700
Links: << >>  << T >>  << A >>
Hey Javid,
Using Synplify? Look up syn_direct_enable in the manual.
Cheers, Syms.



Article: 69329
Subject: Re: How to drive record fields from procedure AND testbench?
From: mike_treseler@comcast.net (Mike Treseler)
Date: 6 May 2004 10:59:46 -0700
Links: << >>  << T >>  << A >>
Peter Sommerfeld wrote:

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

You have stumbled onto the procedure scope problem.
Re-read that thread and see the lines I added
to my example architecture below.

     -- Mike Treseler
     
     
------------------------------------------------------------
architecture synth of signal_structure is
   -- note, I changed your type to data in and out signals
   
   type DSPIF_type is
      record
         DSPaddr     : std_logic_vector(23 downto 0);
         DSPdata_in  : std_logic_vector(31 downto 0);
         DSPdata_out : std_logic_vector(31 downto 0);
         nDHOLD      : std_logic;
         nDHOLDA     : std_logic;
         nDPAGE      : std_logic_vector(3 downto 0);
         nDSTRB      : std_logic;
         nDBE        : std_logic_vector(3 downto 0);
         nDOE        : std_logic;
         nDWE        : std_logic;
         nDRDY       : std_logic;
      end record;

   signal gaggle         : DSPIF_type;
   signal output_enabled : boolean;
-------------------------------------------------------------------------------
   -- Added proc example in scope
   procedure InitBus( signal gaggle: inout DSPIF_type )
   is begin end InitBus;
-------------------------------------------------------------------------------   
begin
   -- wire up signal structure to pins
   gaggle.DSPaddr    <= DSPaddr;
   gaggle.DSPdata_in <= DSPdata;
-- . . . (rest of INs go here)
-- then OUTs:
            nDHOLD  <= gaggle.nDRDY;
            nDRDY   <= gaggle.nDRDY;
            DSPdata <= gaggle.DSPdata_out when output_enabled
                                          else (DSPdata'range => 'Z');

-- processes using the gaggle signals go here

end architecture synth;
   

   -- Mike Treseler

Article: 69330
Subject: Re: Wire crossing in a large partially reconfigurable design.
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Thu, 06 May 2004 22:00:10 GMT
Links: << >>  << T >>  << A >>

"Student" <student@nowhere.com> wrote in message
news:409866a1@news.starhub.net.sg...
> Hi, there:
>
> I am compiling a design which takes up 80% of the XC2V6000...After I put
in
> the
> bus macros and run implementation, I found that there are a large number
of
> wire
> crossings...For example, some VCC_FAKE_LEFT can route as long as three
> slices
> into the Right...vice versa...These wires just run into a switch boxes on
> the opposite
> side then flip back, but not connected to any slices I think...The same
> phenomenon
> never happened in my previous design which only uses 30% of the FPGA...
>
> Is this acceptable for a partially reconfigurable design?
>
> Best Regards,
> Kelvin
>
Just as with sausages, you don't want to delve too deeply into the
construction of an implemented FPGA.  The router uses an iterative process
which might not yield the perfect solution, but usually one that works.
Even if it's not perfect, there's not much you can do about it.  Just try
some hand routing and you will be happy to let the router work on its own.
-Kevin



Article: 69331
Subject: Re: Partial Reconfiguration
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 07 May 2004 08:06:13 +1000
Links: << >>  << T >>  << A >>
Sean Durkin wrote:
> ssaleem wrote:
> 
>> Can someone tell me about the steps to partially reconfigure Vertex-II
>> FPGA's with some simple example? 
> 
> I recommend Application Note 290:
> 
> http://www.xilinx.com/bvdocs/appnotes/xapp290.pdf
> 
> There are no really simple examples for partial reconfiguration, since 
> it just is not that simple...

The simplest way I know to actually demonstrate partial reconfig is to 
hand edit a trivial design in fpga_editor, eg route vcc to an IOB, 
generate the NCD file, run bitgen to get a .bit file, then edit the NCD 
again but route that same IOB to ground, save the new NCD, re-run bitgen 
with the -r option, to create a partial bitstream relative to the first one.

Then, configure with the first bitstream, the IOB goes high (choose one 
that's connected to an LED on the board), then download the partial 
bitstream, the LED should turn off.

Congratulations, you have entered the race for the most complicated 
blinkenlight application, just like the rest of us!

So, it's partial reconfig, but entirely useless.  Next, start exploring 
the tools to generate partial bitstreams in a modular fashion.  Feel 
free to subscribe to the partial-reconfig mailing list, and ask 
questions/discuss there.  It's quiet, but still interesting:

email majorodomo@itee.uq.edu.au, with *body text*
"subscribe partial-reconfig" (no quotes)

Regards,

John

Article: 69332
Subject: Re: Wire crossing in a large partially reconfigurable design.
From: Ray Andraka <ray@andraka.com>
Date: Thu, 06 May 2004 21:14:14 -0400
Links: << >>  << T >>  << A >>
This is an artifact of Xilinx's place and route must finish faster philosophy.
It used to be that if you got a good placement, the route would be near optimal
for that placement.  As devices got bigger, the route time increased too much
for auto-placed designs, so now the router only works as hard as it needs to to
meet timing.  The result is you get many routes that do not take the shortest
path, and worse, many nets become the critical path.  In a densely placed
design, the result is the routing gets congested and the tools may not find a
routing solution that meets timing at all.  Apparently, not many of Xilinx's
big customers are running the FPGAs at the top of the performance envelope,
because if they were I am sure this would be a much highr priority issue.

As for partial reconfiguration, this behavior is a train-wreck.  In order to be
successful, you need to keep the routing within the slices you are
reconfiguring.  The current tools have no apparent way of putting fences around
the logic to keep a route in or out of an area.

Student wrote:

> Hi, there:
>
> I am compiling a design which takes up 80% of the XC2V6000...After I put in
> the
> bus macros and run implementation, I found that there are a large number of
> wire
> crossings...For example, some VCC_FAKE_LEFT can route as long as three
> slices
> into the Right...vice versa...These wires just run into a switch boxes on
> the opposite
> side then flip back, but not connected to any slices I think...The same
> phenomenon
> never happened in my previous design which only uses 30% of the FPGA...
>
> Is this acceptable for a partially reconfigurable design?
>
> Best Regards,
> Kelvin

--
--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: 69333
Subject: Re: How to drive record fields from procedure AND testbench?
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 6 May 2004 18:30:17 -0700
Links: << >>  << T >>  << A >>
Hi Mike,

Yes I found my problem, and it was unfortunately in a part of my
record that I didn't post. In my record, I had a field that was of the
physical type time which I was using inside my procedures for certain
delays. ie:

  type rec is record
    ...
    clock_period : time;
    ...
  end record;

So while I was assuming a signal-driving issue to be the problem, it
was this field (which is still bizarre, because I set this field only
once and never write it again, therefore, I would have thought, it
could not be a problem). Anyways, I replaced this field with a clock
signal which makes more sense now anyways and everything works great,
and thanks to yours and Jim's replies, I understand what's going on
much better too. I had better post the whole thing the next time I
have a problem like this.

-- Pete

> Peter Sommerfeld wrote:
> 
> > 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. 
> 
> You have stumbled onto the procedure scope problem.
> Re-read that thread and see the lines I added
> to my example architecture below.
> 
>      -- Mike Treseler
>      
>      
> ------------------------------------------------------------
> architecture synth of signal_structure is
>    -- note, I changed your type to data in and out signals
>    
>    type DSPIF_type is
>       record
>          DSPaddr     : std_logic_vector(23 downto 0);
>          DSPdata_in  : std_logic_vector(31 downto 0);
>          DSPdata_out : std_logic_vector(31 downto 0);
>          nDHOLD      : std_logic;
>          nDHOLDA     : std_logic;
>          nDPAGE      : std_logic_vector(3 downto 0);
>          nDSTRB      : std_logic;
>          nDBE        : std_logic_vector(3 downto 0);
>          nDOE        : std_logic;
>          nDWE        : std_logic;
>          nDRDY       : std_logic;
>       end record;
> 
>    signal gaggle         : DSPIF_type;
>    signal output_enabled : boolean;
> -------------------------------------------------------------------------------
>    -- Added proc example in scope
>    procedure InitBus( signal gaggle: inout DSPIF_type )
>    is begin end InitBus;
> -------------------------------------------------------------------------------   
> begin
>    -- wire up signal structure to pins
>    gaggle.DSPaddr    <= DSPaddr;
>    gaggle.DSPdata_in <= DSPdata;
> -- . . . (rest of INs go here)
> -- then OUTs:
>             nDHOLD  <= gaggle.nDRDY;
>             nDRDY   <= gaggle.nDRDY;
>             DSPdata <= gaggle.DSPdata_out when output_enabled
>                                           else (DSPdata'range => 'Z');
> 
> -- processes using the gaggle signals go here
> 
> end architecture synth;
>    
> 
>    -- Mike Treseler

Article: 69334
Subject: Re: Wire crossing in a large partially reconfigurable design.
From: "Student" <student@nowhere.com>
Date: Fri, 7 May 2004 12:57:58 +0800
Links: << >>  << T >>  << A >>
I tried to define a guard area on the 8 slices where I placed the Bus
Macros, basically I defined
some additional area_groups  to contain the placement of submodules, leaving
the 8 slices gap
not filled by much logic...

The wire crossing got better, but never gone...

What other tricks may I try?

Best Regards,
Kelvin





"Ray Andraka" <ray@andraka.com> wrote in message
news:409AE2E6.F229545C@andraka.com...
> This is an artifact of Xilinx's place and route must finish faster
philosophy.
> It used to be that if you got a good placement, the route would be near
optimal
> for that placement.  As devices got bigger, the route time increased too
much
> for auto-placed designs, so now the router only works as hard as it needs
to to
> meet timing.  The result is you get many routes that do not take the
shortest
> path, and worse, many nets become the critical path.  In a densely placed
> design, the result is the routing gets congested and the tools may not
find a
> routing solution that meets timing at all.  Apparently, not many of
Xilinx's
> big customers are running the FPGAs at the top of the performance
envelope,
> because if they were I am sure this would be a much highr priority issue.
>
> As for partial reconfiguration, this behavior is a train-wreck.  In order
to be
> successful, you need to keep the routing within the slices you are
> reconfiguring.  The current tools have no apparent way of putting fences
around
> the logic to keep a route in or out of an area.
>
> Student wrote:
>
> > Hi, there:
> >
> > I am compiling a design which takes up 80% of the XC2V6000...After I put
in
> > the
> > bus macros and run implementation, I found that there are a large number
of
> > wire
> > crossings...For example, some VCC_FAKE_LEFT can route as long as three
> > slices
> > into the Right...vice versa...These wires just run into a switch boxes
on
> > the opposite
> > side then flip back, but not connected to any slices I think...The same
> > phenomenon
> > never happened in my previous design which only uses 30% of the FPGA...
> >
> > Is this acceptable for a partially reconfigurable design?
> >
> > Best Regards,
> > Kelvin
>
> --
> --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: 69335
Subject: Re: How to drive record fields from procedure AND testbench?
From: Jim Lewis <Jim@SynthWorks.com>
Date: Thu, 06 May 2004 23:17:01 -0700
Links: << >>  << T >>  << A >>
Peter,
You can convert time to std_logic_vector by converting
it to integer first:

i_int <= NOW / 1 ns ; -- now an integer value with ns units

time_slv <= std_logic_vector(to_unsigned(i_int, time_slv'length)) ;

Cheers,
Jim

  Sommerfeld wrote:

> Hi Mike,
> 
> Yes I found my problem, and it was unfortunately in a part of my
> record that I didn't post. In my record, I had a field that was of the
> physical type time which I was using inside my procedures for certain
> delays. ie:
> 
>   type rec is record
>     ...
>     clock_period : time;
>     ...
>   end record;
> 
> So while I was assuming a signal-driving issue to be the problem, it
> was this field (which is still bizarre, because I set this field only
> once and never write it again, therefore, I would have thought, it
> could not be a problem). Anyways, I replaced this field with a clock
> signal which makes more sense now anyways and everything works great,
> and thanks to yours and Jim's replies, I understand what's going on
> much better too. I had better post the whole thing the next time I
> have a problem like this.
> 
> -- Pete
> 
> 
>>Peter Sommerfeld wrote:
>>
>>
>>>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. 
>>
>>You have stumbled onto the procedure scope problem.
>>Re-read that thread and see the lines I added
>>to my example architecture below.
>>
>>     -- Mike Treseler
>>     
>>     
>>------------------------------------------------------------
>>architecture synth of signal_structure is
>>   -- note, I changed your type to data in and out signals
>>   
>>   type DSPIF_type is
>>      record
>>         DSPaddr     : std_logic_vector(23 downto 0);
>>         DSPdata_in  : std_logic_vector(31 downto 0);
>>         DSPdata_out : std_logic_vector(31 downto 0);
>>         nDHOLD      : std_logic;
>>         nDHOLDA     : std_logic;
>>         nDPAGE      : std_logic_vector(3 downto 0);
>>         nDSTRB      : std_logic;
>>         nDBE        : std_logic_vector(3 downto 0);
>>         nDOE        : std_logic;
>>         nDWE        : std_logic;
>>         nDRDY       : std_logic;
>>      end record;
>>
>>   signal gaggle         : DSPIF_type;
>>   signal output_enabled : boolean;
>>-------------------------------------------------------------------------------
>>   -- Added proc example in scope
>>   procedure InitBus( signal gaggle: inout DSPIF_type )
>>   is begin end InitBus;
>>-------------------------------------------------------------------------------   
>>begin
>>   -- wire up signal structure to pins
>>   gaggle.DSPaddr    <= DSPaddr;
>>   gaggle.DSPdata_in <= DSPdata;
>>-- . . . (rest of INs go here)
>>-- then OUTs:
>>            nDHOLD  <= gaggle.nDRDY;
>>            nDRDY   <= gaggle.nDRDY;
>>            DSPdata <= gaggle.DSPdata_out when output_enabled
>>                                          else (DSPdata'range => 'Z');
>>
>>-- processes using the gaggle signals go here
>>
>>end architecture synth;
>>   
>>
>>   -- Mike Treseler


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 69336
Subject: Which board to buy? Status of open source tools?
From: deeng_temp@yahoo.com (Joel Hardy)
Date: 6 May 2004 23:17:11 -0700
Links: << >>  << T >>  << A >>
Howdy all,

I'm looking to get an FPGA development board sometime soon.  When I
was in college, I played with what was probably the Xess XSB-300E (fun
stuff: we made a  PCMCIA interface and plugged it into an iPaq... but
that's another story).  That's WAY outside of my price range (<
$200US), but the XSA-50 doesn't look too bad.  Any comments on that
one?  Also, I found this
(www.nuhorizons.com/products/xilinx/spartan3/development-board.html),
which looks considerably better to me, especially since my main
prospective project would benefit from a large amount of fast RAM. 
Any advice?  Is there anything else in the sub-$200 I should look at?

Also, what's the status of open source tools?  (I like to tinker on
the software end of things, too, and I have a bad case of PowerBook
envy, and I haven't seen any software available other than x86 and
big-iron UNIX).  Can they go from VHDL/Verilog all the way to
downloading the file to the chip?  I see that compilation (Icarus
verilog) and downloading (found it in this group's FAQ) work, but what
about place and route?  Icarus' docs say it's a no-go for this; is
there anything else, or must I use the Xilinx tools?  (I guess I have
a Xilinx bias -- it's all I've used, and I don't see much else for
cheap development boards.)

Thanks for the help!
- Joel Hardy

Article: 69337
Subject: Re: How to drive record fields from procedure AND testbench?
From: Jim Lewis <Jim@SynthWorks.com>
Date: Thu, 06 May 2004 23:26:26 -0700
Links: << >>  << T >>  << A >>
Peter,
As a PS to my other post, to date I have found
that if I want to work with a single record,
I have been limited to std_logic family.

I have tried tinkering with integers and resolution
functions, but have had problems with resolving a value
to drive when the record field is not to be driven.
It seems that the resolution function is called at the
block level and there currently no way I could find to
work around this.

This is a topic we are kicking around in the VHDL-200X
effort.  I had wished for it to be part of the fast track
effort and I made a proposal, but it is not clear even to
me that the proposal is the best long term solution, so I
don't want to push it.  My preference is to see what comes
up when we give more time and consideration to the problem.

For more on the vhdl-200x effort, see:
     http://www.eda.org/vhdl-200x

IEEE standards are open to public participation.

Best Regards,
Jim


> Hi Mike,
> 
> Yes I found my problem, and it was unfortunately in a part of my
> record that I didn't post. In my record, I had a field that was of the
> physical type time which I was using inside my procedures for certain
> delays. ie:
> 
>   type rec is record
>     ...
>     clock_period : time;
>     ...
>   end record;
> 
> So while I was assuming a signal-driving issue to be the problem, it
> was this field (which is still bizarre, because I set this field only
> once and never write it again, therefore, I would have thought, it
> could not be a problem). Anyways, I replaced this field with a clock
> signal which makes more sense now anyways and everything works great,
> and thanks to yours and Jim's replies, I understand what's going on
> much better too. I had better post the whole thing the next time I
> have a problem like this.
> 
> -- Pete
> 
> 
>>Peter Sommerfeld wrote:
>>
>>
>>>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. 
>>
>>You have stumbled onto the procedure scope problem.
>>Re-read that thread and see the lines I added
>>to my example architecture below.
>>
>>     -- Mike Treseler
>>     
>>     
>>------------------------------------------------------------
>>architecture synth of signal_structure is
>>   -- note, I changed your type to data in and out signals
>>   
>>   type DSPIF_type is
>>      record
>>         DSPaddr     : std_logic_vector(23 downto 0);
>>         DSPdata_in  : std_logic_vector(31 downto 0);
>>         DSPdata_out : std_logic_vector(31 downto 0);
>>         nDHOLD      : std_logic;
>>         nDHOLDA     : std_logic;
>>         nDPAGE      : std_logic_vector(3 downto 0);
>>         nDSTRB      : std_logic;
>>         nDBE        : std_logic_vector(3 downto 0);
>>         nDOE        : std_logic;
>>         nDWE        : std_logic;
>>         nDRDY       : std_logic;
>>      end record;
>>
>>   signal gaggle         : DSPIF_type;
>>   signal output_enabled : boolean;
>>-------------------------------------------------------------------------------
>>   -- Added proc example in scope
>>   procedure InitBus( signal gaggle: inout DSPIF_type )
>>   is begin end InitBus;
>>-------------------------------------------------------------------------------   
>>begin
>>   -- wire up signal structure to pins
>>   gaggle.DSPaddr    <= DSPaddr;
>>   gaggle.DSPdata_in <= DSPdata;
>>-- . . . (rest of INs go here)
>>-- then OUTs:
>>            nDHOLD  <= gaggle.nDRDY;
>>            nDRDY   <= gaggle.nDRDY;
>>            DSPdata <= gaggle.DSPdata_out when output_enabled
>>                                          else (DSPdata'range => 'Z');
>>
>>-- processes using the gaggle signals go here
>>
>>end architecture synth;
>>   
>>
>>   -- Mike Treseler


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 69338
Subject: Re: Mutiple Quartus Instances?
From: Petter Gustad <newsmailcomp5@gustad.com>
Date: 07 May 2004 09:12:08 +0200
Links: << >>  << T >>  << A >>
"Kenneth Land" <kland1@neuralog1.com1> writes:

> Anyone know if there are any gotcha's with working with multiple Quartus (II
> v. 4) projects on the same computer?
> 
> I'd like to work several approaches simultaneously, but not if there are
> side effects - subtle or otherwise.

I naver had any problem with multiple projects and Quartus under Linux
and Solaris at least. However, I'm using mostly scripts in my flow,
and minimal amount of GUI.

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: 69339
Subject: Re: Which board to buy? Status of open source tools?
From: jon@beniston.com (Jon Beniston)
Date: 7 May 2004 06:00:14 -0700
Links: << >>  << T >>  << A >>
> Also, what's the status of open source tools?  (I like to tinker on
> the software end of things, too, and I have a bad case of PowerBook
> envy, and I haven't seen any software available other than x86 and
> big-iron UNIX).  Can they go from VHDL/Verilog all the way to
> downloading the file to the chip?  I see that compilation (Icarus
> verilog) and downloading (found it in this group's FAQ) work, but what
> about place and route?  Icarus' docs say it's a no-go for this; is
> there anything else, or must I use the Xilinx tools?  (I guess I have
> a Xilinx bias -- it's all I've used, and I don't see much else for
> cheap development boards.)

Why bother with Open Source stuff when various incarnations of
commerical tools are free to use? Check out for the Xilinx WebPack:

http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack

Cheers,
JonB

Article: 69340
Subject: Re: Which board to buy? Status of open source tools?
From: johnjakson@yahoo.com (john jakson)
Date: 7 May 2004 06:27:32 -0700
Links: << >>  << T >>  << A >>
deeng_temp@yahoo.com (Joel Hardy) wrote in message news:<91268129.0405062217.35c0b0cd@posting.google.com>...
> Howdy all,
> 
> I'm looking to get an FPGA development boarXess XSB-300E (fun
> stuff: we made a  PCMCIA interface and plugged it into an iPaq... but
> that's another story).  That's WAY outside of my price range (<
> $200US), but the XSA-50 doesn't lookd sotoo bad.  Any comments on that
> one?  Also, I found thisprobably the  anything else in the sub-$200 I should look at?
> 
> Also, what's the status of open source tools?  (I like to tinker on
> the software end of things, too, and I have a bad case of PowerBook
> envy, and I haven't seen any software available o
> (www.nuhorizons.com/products/xilinx/spartan3/development-board.html),
> which looks considerably better to me, especially since my main
> prospective project would benefit from a large amount of fast RAM. 
> Any advice?  Is there metime soon.  When I
> was in college, I played with what was ther than x86 and
> big-iron UNIX).  Can they go from VHDL/Verilog all the way to
> downloading the file to the chip?  I see that compilation (Icarus
> verilog) and downloading (found it in this group's FAQ) work, but what
> about place and route?  Icarus' docs say it's a no-go for this; is
> there anything else, or must I use the Xilinx tools?  (I guess I have
> a Xilinx bias -- it's all I've used, and I don't see much else for
> cheap development boards.)
> 
> Thanks for the help!
> - Joel Hardy


Apart from entry level HDL simulation, I wouldn't expect too much from
open source for anything really difficult. The structure of FPGAs is
generally too complicated & proprietary for opensource. It was
different when everyone was doing ASIC & polygon design, then anyone
could write code that would work with any vendor.

You can run the free WebPack under VPC for Mac and take the speed hit,
interested to see a comparison of that v near equiv x86 running
native. I'd bet its 10x slower.

you can google geda, open source eda tools, there are quite a few out
there but mostly not much updated. Also hang out in the verilog/vhdl
NGs.

regards

johnjakson_usa_com

Article: 69341
Subject: Re: Mutiple Quartus Instances?
From: "Subroto Datta" <sdatta@altera.com>
Date: Fri, 07 May 2004 13:30:08 GMT
Links: << >>  << T >>  << A >>

"Kenneth Land" <kland1@neuralog1.com1> wrote in message
news:109kls5eqph5vcc@news.supernews.com...
> Anyone know if there are any gotcha's with working with multiple Quartus
(II
> v. 4) projects on the same computer?
>

Hi Ken,

    Based on the Quartus architecture you should not:

1. Open the SAME project in multiple Quartus instances, i.e. each Quartus
instance should work on a different project.

2. Do not open a project from the UI and then run the command line compiler
executables from a DOS prompt/command shell (quartus_map, quartus_fit,
quartus_tan, quartus_asm ...) on the same project. Use the UI or the command
line exclusively at any point in your design flow. You can switch between
the two as needed.

3. Don't open and/or close more than one instance of Quartus at exactly the
SAME time. Basically, if one instance of Quartus is trying to close down, it
is in the process of writing stuff to the registry. Then during that time,
another instance of Quartus just starting up may be trying to read that data
whcih may not be correct. Therefore if you initiate a closing of a Quartus
instance let it close fully before you open another one.

Apart from these you are ready to go. Hope this helps.

- Subroto Datta
Altera Corp.





Article: 69342
Subject: Re: How to drive record fields from procedure AND testbench?
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 7 May 2004 07:15:37 -0700
Links: << >>  << T >>  << A >>
Hi Jim,

Yes I would love to participate in the VHDL-200X effort. It's nice to
see it's open to the non-members. Is there a target release date for
VHDL-200X?

This problem of the fields of a record appearing to be resolved as a
group, and not individually, is particularly vexing to me. Hopefully I
won't have to deal with it in the next VHDL version.

-- Pete


> Peter,
> As a PS to my other post, to date I have found
> that if I want to work with a single record,
> I have been limited to std_logic family.
> 
> I have tried tinkering with integers and resolution
> functions, but have had problems with resolving a value
> to drive when the record field is not to be driven.
> It seems that the resolution function is called at the
> block level and there currently no way I could find to
> work around this.
> 
> This is a topic we are kicking around in the VHDL-200X
> effort.  I had wished for it to be part of the fast track
> effort and I made a proposal, but it is not clear even to
> me that the proposal is the best long term solution, so I
> don't want to push it.  My preference is to see what comes
> up when we give more time and consideration to the problem.
> 
> For more on the vhdl-200x effort, see:
>      http://www.eda.org/vhdl-200x
> 
> IEEE standards are open to public participation.
> 
> Best Regards,
> Jim
> 
> 
> > Hi Mike,
> > 
> > Yes I found my problem, and it was unfortunately in a part of my
> > record that I didn't post. In my record, I had a field that was of the
> > physical type time which I was using inside my procedures for certain
> > delays. ie:
> > 
> >   type rec is record
> >     ...
> >     clock_period : time;
> >     ...
> >   end record;
> > 
> > So while I was assuming a signal-driving issue to be the problem, it
> > was this field (which is still bizarre, because I set this field only
> > once and never write it again, therefore, I would have thought, it
> > could not be a problem). Anyways, I replaced this field with a clock
> > signal which makes more sense now anyways and everything works great,
> > and thanks to yours and Jim's replies, I understand what's going on
> > much better too. I had better post the whole thing the next time I
> > have a problem like this.
> > 
> > -- Pete
> > 
> > 
> >>Peter Sommerfeld wrote:
> >>
> >>
> >>>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. 
> >>
> >>You have stumbled onto the procedure scope problem.
> >>Re-read that thread and see the lines I added
> >>to my example architecture below.
> >>
> >>     -- Mike Treseler
> >>     
> >>     
> >>------------------------------------------------------------
> >>architecture synth of signal_structure is
> >>   -- note, I changed your type to data in and out signals
> >>   
> >>   type DSPIF_type is
> >>      record
> >>         DSPaddr     : std_logic_vector(23 downto 0);
> >>         DSPdata_in  : std_logic_vector(31 downto 0);
> >>         DSPdata_out : std_logic_vector(31 downto 0);
> >>         nDHOLD      : std_logic;
> >>         nDHOLDA     : std_logic;
> >>         nDPAGE      : std_logic_vector(3 downto 0);
> >>         nDSTRB      : std_logic;
> >>         nDBE        : std_logic_vector(3 downto 0);
> >>         nDOE        : std_logic;
> >>         nDWE        : std_logic;
> >>         nDRDY       : std_logic;
> >>      end record;
> >>
> >>   signal gaggle         : DSPIF_type;
> >>   signal output_enabled : boolean;
> >>-------------------------------------------------------------------------------
> >>   -- Added proc example in scope
> >>   procedure InitBus( signal gaggle: inout DSPIF_type )
> >>   is begin end InitBus;
> >>-------------------------------------------------------------------------------   
> >>begin
> >>   -- wire up signal structure to pins
> >>   gaggle.DSPaddr    <= DSPaddr;
> >>   gaggle.DSPdata_in <= DSPdata;
> >>-- . . . (rest of INs go here)
> >>-- then OUTs:
> >>            nDHOLD  <= gaggle.nDRDY;
> >>            nDRDY   <= gaggle.nDRDY;
> >>            DSPdata <= gaggle.DSPdata_out when output_enabled
> >>                                          else (DSPdata'range => 'Z');
> >>
> >>-- processes using the gaggle signals go here
> >>
> >>end architecture synth;
> >>   
> >>
> >>   -- Mike Treseler
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 69343
Subject: Virtex2 (500) DCM Frequency Synthesize
From: furia1024@wp.pl (Jerzy)
Date: 7 May 2004 07:49:57 -0700
Links: << >>  << T >>  << A >>
Hello
I've got following problem:
I need 27MHz and 54MHz clocks, input freq. is 20MHz.
Till today I used DCM FS 27/20 next to DLL and DLL*2.
Theoreticly it should works OK, but doesn't. From time to time after
reboot or after clok stop, it works strange and completly bad. Today
I've read about jitter on output of DCM's CLKFX, I check on "Virtex-II
CLKFX Jitter Calculator" that in this conditions I have over 2 ns
jitter on CLKFX output, which is to big for DLL input CLKIN.
So I try to do this way:
DCM FS 27/5 - I have 108MHz next to DLL/4 and DLL*2
The jitter on CLKFX should be below 1ns and now it must work but
doesn't.
What should I check else?
Please help me, I lose my hair :>

Best regards
Jerzy Gbur

Article: 69344
Subject: Error while simulation with XILINX DCM
From: foag@iti.uni-luebeck.de (J?rgen)
Date: 7 May 2004 07:54:41 -0700
Links: << >>  << T >>  << A >>
Hi,
in order to verify the functionality of XILINX DCM, I have generated a
dcm.vhd file with the ISE 6.2 architecture wizard. The dcm module is
embedded into a simple top-level file that only connects the testbench
signals (in-clock and reset (=0) to the DCM-module. The DCM reset
signal is always set to '0'.

Unfortunately, during the simulation with Modelsim, I do not obtain
the 4x clock signal of the input clock at the output (CLKFX_OUT) but
always '0'. CLK0_OUT is always '0', but CLKIN_IBUFG_OUT follows the
input clock signal.

What can be the reason for this behavior ?

Regards
Juergen

------------------------------------------------------------------------------
Below: the dcm file generated by architecture wizard

-- Module dyna_dcm
-- Generated by Xilinx Architecture Wizard
-- VHDL
-- Written for synthesis tool: XST

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
-- synopsys translate_off
Library UNISIM;
use UNISIM.Vcomponents.all;
-- synopsys translate_on

entity dyna_dcm is
    port (
        RST_IN : in std_logic;
        CLKIN_IN : in std_logic;
        LOCKED_OUT : out std_logic;
        CLKFX_OUT : out std_logic;
        CLKIN_IBUFG_OUT : out std_logic;
        CLK0_OUT : out std_logic);
end dyna_dcm;

architecture STRUCT of dyna_dcm is
   signal CLKIN_IBUFG : std_logic;
   signal CLKFB_IN : std_logic;
   signal CLK0_BUF : std_logic;
   signal CLKFX_BUF : std_logic;
   signal GND : std_logic;

-- Period Jitter (unit interval) = 0.17 UI
-- Period Jitter (Peak-to-Peak) = 0.63 ns

   component DCM
    generic( 
       CLKDV_DIVIDE : real := 2.0;
       CLKFX_DIVIDE : integer := 1;
       CLKFX_MULTIPLY : integer := 4;
       CLKIN_DIVIDE_BY_2 : boolean := false;
       CLKIN_PERIOD : real := 0.0;                         
       CLKOUT_PHASE_SHIFT : string := "NONE";
       CLK_FEEDBACK : string := "1X";
       DESKEW_ADJUST : string := "SYSTEM_SYNCHRONOUS";     
       DFS_FREQUENCY_MODE : string := "LOW";
       DLL_FREQUENCY_MODE : string := "LOW";
       DSS_MODE : string := "NONE";                        
       DUTY_CYCLE_CORRECTION : boolean := true;
       FACTORY_JF : bit_vector := X"C080";                 
       MAXPERCLKIN : time := 1000000 ps;                   
       MAXPERPSCLK : time := 100000000 ps;                 
       PHASE_SHIFT : integer := 0;
       SIM_CLKIN_CYCLE_JITTER : time := 300 ps;            
       SIM_CLKIN_PERIOD_JITTER : time := 1000 ps;          
       STARTUP_WAIT : boolean := false                     
     );
     port (
       CLKIN : in std_logic;
       CLKFB : in std_logic;
       RST : in std_logic;
       PSEN : in std_logic;
       PSINCDEC : in std_logic;
       PSCLK : in std_logic;
       DSSEN : in std_logic;
       CLK0 : out std_logic;
       CLK90 : out std_logic;
       CLK180 : out std_logic;
       CLK270 : out std_logic;
       CLKDV : out std_logic;
       CLK2X : out std_logic;
       CLK2X180 : out std_logic;
       CLKFX : out std_logic;
       CLKFX180 : out std_logic;
       STATUS : out std_logic_vector (7 downto 0);
       LOCKED : out std_logic;
       PSDONE : out std_logic
       );
   end component;
   component IBUFG
     port (
       I : in std_logic;
       O : out std_logic
       );
   end component;
   component BUFG
     port (
       I : in std_logic;
       O : out std_logic
       );
   end component;

begin
   DCM_INST : DCM
    Generic map (
      CLK_FEEDBACK => "1X",
      CLKDV_DIVIDE => 2.0,
      CLKFX_DIVIDE => 1,
      CLKFX_MULTIPLY => 4,
      CLKIN_DIVIDE_BY_2 => FALSE,
      CLKIN_PERIOD => 15.1515,
      CLKOUT_PHASE_SHIFT => "NONE",
      DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
      DFS_FREQUENCY_MODE => "HIGH",
      DLL_FREQUENCY_MODE => "LOW",
      DUTY_CYCLE_CORRECTION => TRUE,
      PHASE_SHIFT => 0,
      STARTUP_WAIT => FALSE)
     port map (
      CLKIN => CLKIN_IBUFG,
      CLKFB => CLKFB_IN,
      RST => RST_IN,
      PSEN => GND,
      PSINCDEC => GND,
      PSCLK => GND,
      DSSEN => GND,
      CLK0 => CLK0_BUF,
      CLKFX => CLKFX_BUF,
      LOCKED => LOCKED_OUT);

   CLKIN_IBUFG_INST : IBUFG
     port map (
      I => CLKIN_IN,
      O => CLKIN_IBUFG);

   CLK0_BUFG_INST : BUFG
     port map (
      I => CLK0_BUF,
      O => CLKFB_IN);

   CLKFX_BUFG_INST : BUFG
     port map (
      I => CLKFX_BUF,
      O => CLKFX_OUT);

   CLKIN_IBUFG_OUT <= CLKIN_IBUFG;
   CLK0_OUT <= CLKFB_IN;
   GND <= '0';
end STRUCT;

Article: 69345
Subject: Re: Virtex2 (500) DCM Frequency Synthesize
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 07 May 2004 08:20:24 -0700
Links: << >>  << T >>  << A >>
Jerzy,

Since it sounds like you are cascading two DCMs, you must hold the 
second DCM in reset until the first has locked.

Cascading two DCMs from a CLKFX to a CLKIN to a CLKFX is not 
recommended, but has been characterized to work under most situations 
where the jitter from the first DCM does not exceed the requirement of 
the second DCM.

It is not recommended to have a CLKFX out to a CLKIN to a CLK0 (CLKDV, 
CLK2X) out (use of DLL) as this is a very poor cascade.  The CLK0 should 
always come from the first DCM to the CLKIN of the second DCM which 
generates the CLKFX (if the frequencies work out).

It would be better to just take the 108 MHz from the first DCM and 
divide it down with a synchronous counter to get the 27 and 54 MHz 
signals, why use another DCM?  This also reduces the jitter as a 
percentage of the period.

Not that I do not appreciate designers using every DCM they can (after 
all, I was on the team that designed it), the DCM is a short-cut to 
doing true synchonous design (with clock enables)!

Do not forget using the old simple techniques from years past, either.

Austin

Jerzy wrote:
> Hello
> I've got following problem:
> I need 27MHz and 54MHz clocks, input freq. is 20MHz.
> Till today I used DCM FS 27/20 next to DLL and DLL*2.
> Theoreticly it should works OK, but doesn't. From time to time after
> reboot or after clok stop, it works strange and completly bad. Today
> I've read about jitter on output of DCM's CLKFX, I check on "Virtex-II
> CLKFX Jitter Calculator" that in this conditions I have over 2 ns
> jitter on CLKFX output, which is to big for DLL input CLKIN.
> So I try to do this way:
> DCM FS 27/5 - I have 108MHz next to DLL/4 and DLL*2
> The jitter on CLKFX should be below 1ns and now it must work but
> doesn't.
> What should I check else?
> Please help me, I lose my hair :>
> 
> Best regards
> Jerzy Gbur

Article: 69346
Subject: Re: Which board to buy? Status of open source tools?
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Fri, 7 May 2004 17:21:11 +0200
Links: << >>  << T >>  << A >>

"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0405070500.7c9c4bcc@posting.google.com...
> > Also, what's the status of open source tools?  (I like to tinker on
> > the software end of things, too, and I have a bad case of PowerBook
> > envy, and I haven't seen any software available other than x86 and
> > big-iron UNIX).  Can they go from VHDL/Verilog all the way to
> > downloading the file to the chip?  I see that compilation (Icarus
> > verilog) and downloading (found it in this group's FAQ) work, but what
> > about place and route?  Icarus' docs say it's a no-go for this; is
> > there anything else, or must I use the Xilinx tools?  (I guess I have
> > a Xilinx bias -- it's all I've used, and I don't see much else for
> > cheap development boards.)
>
> Why bother with Open Source stuff when various incarnations of
> commerical tools are free to use? Check out for the Xilinx WebPack:
>
> http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack
>

I think you misunderstand the point of Open Source - price is only one
aspect (and open source software is not necessarily free, although normally
you can find any given open source program somewhere for free downloading.
Frequently you can buy pre-packaged CD's, often with support, such as Linux
distributions or the OpenTech cdrom
http://www.opencores.org/projects.cgi/web/opentech/about ).

The original poster was looking for open source tools because he likes to
tinker with the software, and because he wants to run the software on
something other than an x86 machine.  That is possible with open source
software, but not with free closed source software.

Sites worth looking at are http://www.opencores.org ,
http://opencollector.org/ , and http://geda.seul.org .  But as another
poster pointed out, there are good reasons why place and route software
tends to be proprietry.





Article: 69347
Subject: Re: Mutiple Quartus Instances?
From: george.martin@att.net (George)
Date: 7 May 2004 09:01:29 -0700
Links: << >>  << T >>  << A >>
Petter Gustad <newsmailcomp5@gustad.com> wrote in message news:<m3hdus1zjr.fsf@scimul.dolphinics.no>...
> "Kenneth Land" <kland1@neuralog1.com1> writes:
> 
> > Anyone know if there are any gotcha's with working with multiple Quartus (II
> > v. 4) projects on the same computer?
> > 
> > I'd like to work several approaches simultaneously, but not if there are
> > side effects - subtle or otherwise.
> 
> I naver had any problem with multiple projects and Quartus under Linux
> and Solaris at least. However, I'm using mostly scripts in my flow,
> and minimal amount of GUI.
> 
> Petter

I've got several projects running in Quartus with no porblems.  The
problem/opportunity you will come across is when an upgrade to Quartus
is released.  Upgrading could cause you to recompile old projects and
perhaps changing something by surprise.

George

Article: 69348
Subject: Re: How to drive record fields from procedure AND testbench?
From: Jim Lewis <Jim@SynthWorks.com>
Date: Fri, 07 May 2004 09:21:25 -0700
Links: << >>  << T >>  << A >>
Peter,
> Yes I would love to participate in the VHDL-200X effort. It's nice to
> see it's open to the non-members. Is there a target release date for
> VHDL-200X?
VHDL-200X is a multi-phased effort.

The first phase is fast-track.  These are critical update
items.  It is due to have ready for ballot some time this
year.  Details on this are at:
    http://www.eda.org/vhdl-200x/vhdl-200x-ft

There are things that will go out with FT that are not on
the FT proposal list.  These are items from the other
groups that are working them as separate issues.

> This problem of the fields of a record appearing to be resolved as a
> group, and not individually, is particularly vexing to me. Hopefully I
> won't have to deal with it in the next VHDL version.

It has been vexing me too.  I don't think we will have the
solution for fast track, however, it is one of my high
priorities so I will be pushing for it making the revision
that follows fast track.

Cheers,
Jim


>>Peter,
>>As a PS to my other post, to date I have found
>>that if I want to work with a single record,
>>I have been limited to std_logic family.
>>
>>I have tried tinkering with integers and resolution
>>functions, but have had problems with resolving a value
>>to drive when the record field is not to be driven.
>>It seems that the resolution function is called at the
>>block level and there currently no way I could find to
>>work around this.
>>
>>This is a topic we are kicking around in the VHDL-200X
>>effort.  I had wished for it to be part of the fast track
>>effort and I made a proposal, but it is not clear even to
>>me that the proposal is the best long term solution, so I
>>don't want to push it.  My preference is to see what comes
>>up when we give more time and consideration to the problem.
>>
>>For more on the vhdl-200x effort, see:
>>     http://www.eda.org/vhdl-200x
>>
>>IEEE standards are open to public participation.
>>
>>Best Regards,
>>Jim
>>
>>
>>
>>>Hi Mike,
>>>
>>>Yes I found my problem, and it was unfortunately in a part of my
>>>record that I didn't post. In my record, I had a field that was of the
>>>physical type time which I was using inside my procedures for certain
>>>delays. ie:
>>>
>>>  type rec is record
>>>    ...
>>>    clock_period : time;
>>>    ...
>>>  end record;
>>>
>>>So while I was assuming a signal-driving issue to be the problem, it
>>>was this field (which is still bizarre, because I set this field only
>>>once and never write it again, therefore, I would have thought, it
>>>could not be a problem). Anyways, I replaced this field with a clock
>>>signal which makes more sense now anyways and everything works great,
>>>and thanks to yours and Jim's replies, I understand what's going on
>>>much better too. I had better post the whole thing the next time I
>>>have a problem like this.
>>>
>>>-- Pete
>>>
>>>
>>>
>>>>Peter Sommerfeld wrote:
>>>>
>>>>
>>>>
>>>>>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. 
>>>>
>>>>You have stumbled onto the procedure scope problem.
>>>>Re-read that thread and see the lines I added
>>>>to my example architecture below.
>>>>
>>>>    -- Mike Treseler
>>>>    
>>>>    
>>>>------------------------------------------------------------
>>>>architecture synth of signal_structure is
>>>>  -- note, I changed your type to data in and out signals
>>>>  
>>>>  type DSPIF_type is
>>>>     record
>>>>        DSPaddr     : std_logic_vector(23 downto 0);
>>>>        DSPdata_in  : std_logic_vector(31 downto 0);
>>>>        DSPdata_out : std_logic_vector(31 downto 0);
>>>>        nDHOLD      : std_logic;
>>>>        nDHOLDA     : std_logic;
>>>>        nDPAGE      : std_logic_vector(3 downto 0);
>>>>        nDSTRB      : std_logic;
>>>>        nDBE        : std_logic_vector(3 downto 0);
>>>>        nDOE        : std_logic;
>>>>        nDWE        : std_logic;
>>>>        nDRDY       : std_logic;
>>>>     end record;
>>>>
>>>>  signal gaggle         : DSPIF_type;
>>>>  signal output_enabled : boolean;
>>>>-------------------------------------------------------------------------------
>>>>  -- Added proc example in scope
>>>>  procedure InitBus( signal gaggle: inout DSPIF_type )
>>>>  is begin end InitBus;
>>>>-------------------------------------------------------------------------------   
>>>>begin
>>>>  -- wire up signal structure to pins
>>>>  gaggle.DSPaddr    <= DSPaddr;
>>>>  gaggle.DSPdata_in <= DSPdata;
>>>>-- . . . (rest of INs go here)
>>>>-- then OUTs:
>>>>           nDHOLD  <= gaggle.nDRDY;
>>>>           nDRDY   <= gaggle.nDRDY;
>>>>           DSPdata <= gaggle.DSPdata_out when output_enabled
>>>>                                         else (DSPdata'range => 'Z');
>>>>
>>>>-- processes using the gaggle signals go here
>>>>
>>>>end architecture synth;
>>>>  
>>>>
>>>>  -- Mike Treseler
>>
>>
>>-- 
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>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
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Article: 69349
Subject: Where did Altera tech support go?????
From: David Rogoff <david@therogoffs.com>
Date: Fri, 07 May 2004 10:04:50 -0700
Links: << >>  << T >>  << A >>

What's going on at Altera!?!?  I've tried a few times to call the tech
support line over the last couple of weeks.  Each time I just end up
on hold forever.  One time, with my speakerphone, I waiting over an
hour before giving up.  I don't want to enter the problem on the
on-line mysupport page, since I know that will take a couple of days
for a response.

I had been calling a direct contact in the company, but he appears to
be out today.  Is there anyone there?  I have a Signal Probe problem I
need resolved ASAP!  If there's someone at Altera reading this, please
contact me at david.rogoff@emulex.com.

Thanks,

 David

p.s. - The tech support line is also very annoying that it makes you
listen to the very long intro message warning that you must use your
Altera ID number and won't let you bypass the message.  Please fix it!



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