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 108150

Article: 108150
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "Antti" <Antti.Lukats@xilant.com>
Date: 6 Sep 2006 00:58:22 -0700
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com schrieb:

> Hi All,
>
> Here is a open-source CableServer replacement,ent for Impact. Currently
> Parallel III and Alter ByteBlaster are supported, but any 3rd party can
> be implemented easily and can be used from Impact.
>
> I've tested only Impact 8.2, if anybody has any problem with 7.1,
> please let me know!
>
> Impact and Xilinx CableServer communication are very pooly written.
> There is no error recovery at all. If server stops, Impact GUI will
> crash. To avoid this you must disconnect server from GUI using
> Output/Cavble disconnect menu.
>
> http://sourceforge.net/projects/xilprg
> http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209
>
> Regards,
>
> Zoltan

Great !! it really works!

so now you can use Impact to connect to ByteBlaster,
or any other custom cable or cable not supported by impact!

Antti


Article: 108151
Subject: Packages for ORCAD
From: in_spb3@yahoo.com
Date: 6 Sep 2006 01:02:03 -0700
Links: << >>  << T >>  << A >>
 Hello.
Do anybody have ORCAD library for Xilinx xc3s1500 in FG320 package and
TI TMS320C6713BGDP300?
 Thanks,
  Dmitry.


Article: 108152
Subject: Re: FIFO with EBR
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 6 Sep 2006 01:07:53 -0700
Links: << >>  << T >>  << A >>
Hello Mike,

>
> If the target fpga has block ram, and if you
> use the recommended code template, no
> attribute hints are required.

thank you for your answer.
Yes the target FPGA (Lattice EC15) does have EBR.
I do not want to use the template generated with the Lattice tool
IPExpress but my own.

Rgds
Andr=E9


Article: 108153
Subject: Re: XPS : Compiler advanced options...
From: "Antti" <Antti.Lukats@xilant.com>
Date: 6 Sep 2006 01:09:00 -0700
Links: << >>  << T >>  << A >>
Alfre schrieb:

> Hi all.
>
> I would like to link my own library file with the standard ones created in EDK by Xilinx. So I had thought to use the advanced compiler options--> I mean set a directory in the -L for the linker and moreover the file in the -l. But it doesn't work: i see the compiler get these options but an error says that not found the library... I'm sure and " have checked more times the path and the library name.
>
> Why? Could be a bug?
>
> I'm using EDK 8.1.02i.
>
> Thanks in advance.
>
> Cheers, Al.

it sure does work in 8.1SP2, you can add libraries to be linked in the
options tab, if those are found they are linked properly - so it most
likely is still something with the path

"Paths" libraries to link against.. there you add your libraries, I
have done that and they are getting linked!

Antti


Article: 108154
Subject: Re: Open-source CableServer for Impact (no more need for Jungo driver on Linux)
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 6 Sep 2006 08:09:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
Daniel O'Connor <darius@dons.net.au> wrote:
> zcsizmadia@gmail.com wrote:
> > I've reversed engineer the CableServer communication with Impact and
> > written from scratch a brand new CableServer. Currently only Parallel
> > III cable is implemented, but new cables can be added very easily. I
> > will post the project on sourceforge.net next week.

> Nice! Good work.

> > Antti wasn't really helpful to come up with a name for the project, so
> > it will be called "cblsrv" :)

> If it doesn't crash like the Xilinx one you could call it "AbleServe" :)

Webpack 8.2, Service Pack 2 claims to fix the Impact crash when the
Bit/Kedec Files changes. Obviously nobody tested, as the crash is still
there...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 108155
Subject: Re: FIFO with EBR
From: "ALuPin@web.de" <ALuPin@web.de>
Date: 6 Sep 2006 01:10:01 -0700
Links: << >>  << T >>  << A >>
Hello Gabor,

thank you for your response.


> Also make sure the FIFO code can be made from block RAM.  In
> Lattice, like Xilinx, the block RAM's have registered outputs, so
> code that implements a combinatorial read function cannot be
> synthesized using EBR.

Yes, I do have the following process in my code:

 PIPETYPE_active: IF PipeType=3D1 GENERATE
 BEGIN
    FIFOOUT_reg: PROCESS(Reset, Clk)
    BEGIN
      IF Reset=3D'1' THEN
         DataOut <=3D (OTHERS =3D> '0');

      ELSIF rising_edge(Clk) THEN
         DataOut <=3D ls_fifo_reg(ls_rptr);
      END IF;

    END PROCESS FIFOOUT_reg;
 END GENERATE PIPETYPE_active;

where "ls_fifo_reg" are the FIFO registers.

Rgds
Andr=E9


Article: 108156
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 6 Sep 2006 09:14:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> Hi All,

> Here is a open-source CableServer replacement for Xilinx Impact.
> Currently Parallel III and Altera ByteBlaster are supported, but any
> 3rd party programmer cable can be implemented easily and can be used
> from Impact. This open-source implementation can be used as a
> Programmer Cable SDK for Impact.

> I've tested only Impact 8.2, if anybody has any problem with 7.1,
> please let me know!

> Impact and Xilinx CableServer communication are very pooly written.
> There is no error recovery at all. If server stops, Impact GUI will
> crash. To avoid this you must disconnect server from GUI using
> Output/Cavble disconnect menu.

> http://sourceforge.net/projects/xilprg
> http://sourceforge.net/project/showfiles.php?\
group_id=175344&package_id=203209
I am trying to run cblsrv on Linux (Suse10.0) with a dlc5 clone (selfmade).
Impact with windrvr recognizes the chain. 
cblsrv -d3 -cdlc5:/dev/parport0 -p 2000 doesn't find the chain.
Obviosly PARPORT_DIRECT needs to get undefined with PARPORT_PPDEV
--- cblsrv-0.1/src/parport.h~   2006-09-06 07:36:08.000000000 +0200
+++ cblsrv-0.1/src/parport.h    2006-09-06 10:35:16.000000000 +0200
@@ -50,6 +50,7 @@
 
 // Define this if you want to support parport access by /dev/parportX
 #if !defined(WIN32) && !defined(__CYGWIN__)
+#undef  PARPORT_DIRECT
 #define PARPORT_PPDEV
 #endif
 
Running as root with direct io works.

After the patch, running with PARPORT_PPDEV and reading the ID results in a
crash of cblsrc:
 
Program received signal SIGSEGV, Segmentation fault.
0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672, 
    wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
306             tdi_byte = *pw++;
(gdb) p pw
$1 = (u8 *) 0x8070000 <Address 0x8070000 out of bounds>
(gdb) bt
#0  0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672, 
    wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
#1  0x0804aedb in cable::write (this=0x804f008, mode=64, wbuff=@0xbf8fea68, 
    cmp_rbuff=@0xbf8fea50) at cable.cpp:345
#2  0x080499db in do_cmd_write () at cblsrv.cpp:258
#3  0x08049f26 in do_msg_commands () at cblsrv.cpp:447
#4  0x0804a35a in client_connection () at cblsrv.cpp:584
#5  0x0804a53a in main (argc=5, argv=0xbf8feb84) at cblsrv.cpp:800

num-bit seems a little off.

Any ideas? Otherwise I'll try to debug in the next days.

B.t.w.: Do you have some smaller test client. Starting impact and clicking a
zillion time to get to some point in the jtag handling is tedious...


-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 108157
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "Antti" <Antti.Lukats@xilant.com>
Date: 6 Sep 2006 02:20:25 -0700
Links: << >>  << T >>  << A >>
Uwe Bonnes schrieb:

> zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> > Hi All,
>
> > Here is a open-source CableServer replacement for Xilinx Impact.
> > Currently Parallel III and Altera ByteBlaster are supported, but any
> > 3rd party programmer cable can be implemented easily and can be used
> > from Impact. This open-source implementation can be used as a
> > Programmer Cable SDK for Impact.
>
> > I've tested only Impact 8.2, if anybody has any problem with 7.1,
> > please let me know!
>
> > Impact and Xilinx CableServer communication are very pooly written.
> > There is no error recovery at all. If server stops, Impact GUI will
> > crash. To avoid this you must disconnect server from GUI using
> > Output/Cavble disconnect menu.
>
> > http://sourceforge.net/projects/xilprg
> > http://sourceforge.net/project/showfiles.php?\
> group_id=175344&package_id=203209
> I am trying to run cblsrv on Linux (Suse10.0) with a dlc5 clone (selfmade).
> Impact with windrvr recognizes the chain.
> cblsrv -d3 -cdlc5:/dev/parport0 -p 2000 doesn't find the chain.
> Obviosly PARPORT_DIRECT needs to get undefined with PARPORT_PPDEV
> --- cblsrv-0.1/src/parport.h~   2006-09-06 07:36:08.000000000 +0200
> +++ cblsrv-0.1/src/parport.h    2006-09-06 10:35:16.000000000 +0200
> @@ -50,6 +50,7 @@
>
>  // Define this if you want to support parport access by /dev/parportX
>  #if !defined(WIN32) && !defined(__CYGWIN__)
> +#undef  PARPORT_DIRECT
>  #define PARPORT_PPDEV
>  #endif
>
> Running as root with direct io works.
>
> After the patch, running with PARPORT_PPDEV and reading the ID results in a
> crash of cblsrc:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> 306             tdi_byte = *pw++;
> (gdb) p pw
> $1 = (u8 *) 0x8070000 <Address 0x8070000 out of bounds>
> (gdb) bt
> #0  0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> #1  0x0804aedb in cable::write (this=0x804f008, mode=64, wbuff=@0xbf8fea68,
>     cmp_rbuff=@0xbf8fea50) at cable.cpp:345
> #2  0x080499db in do_cmd_write () at cblsrv.cpp:258
> #3  0x08049f26 in do_msg_commands () at cblsrv.cpp:447
> #4  0x0804a35a in client_connection () at cblsrv.cpp:584
> #5  0x0804a53a in main (argc=5, argv=0xbf8feb84) at cblsrv.cpp:800
>
> num-bit seems a little off.
>
> Any ideas? Otherwise I'll try to debug in the next days.
>
> B.t.w.: Do you have some smaller test client. Starting impact and clicking a
> zillion time to get to some point in the jtag handling is tedious...
>
>
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

there is no other test client as impact yet.
I assume there will be since the cableserver protocol is now "open" :)

Antti

PS the cblsrv works perfectly on WinXP!


Article: 108158
Subject: Re: Forth-CPU design
From: "rickman" <gnuarm@gmail.com>
Date: 6 Sep 2006 02:57:37 -0700
Links: << >>  << T >>  << A >>
J Thomas wrote:
> rickman wrote:
> > jacko wrote:
>
> > > just wondering if grey code (1 bit change) addressed stack memory might
> > > be useful for cutting down carry chain logic for pre-post dec/inc
> > > addressing??
> >
> > Why bother?  On FPGAs carry chain logic is free, fast and the easy
> > path.  I guess you are thinking custom chip, eh?
>
> I wasn't sure I understood the question. Is it to reduce the worst-case
> speed for the increment? A traditional carry-type grey code implement
> has a worst case just as bad as binary, but it sounds like he's
> thinking about dedicating the space for a faster method.
>
> But likely I misunderstood. Why would he need the increment to be fast
> when something else would surely be slower anyway? And I'd expect a
> binary increment to take less space.

Yes, there are few advantages to a Gray code counter.  But one is a
lower power consumption because only one bit changes on each increment.
 Again this is unlikely to be noticed in a real chip given the small
size of the counter.


Article: 108159
Subject: Re: Exploring Quartus' Messages and Warnings
From: "alterauser" <fpgaengineerfrankfurt@arcor.de>
Date: 6 Sep 2006 03:41:16 -0700
Links: << >>  << T >>  << A >>
@both:

Right-clicking and trying to locate it, brought no result, however. :-(

I know about the section "ignored timing reqs". - was empty in this
case.


Article: 108160
Subject: RLOC problems
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Wed, 6 Sep 2006 11:33:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
I'm playing around a bit with RLOC and I'm getting some weird
results. 

My top level file has these instantiations in it:

   (* RLOC =  "X0Y0" *) rloc_reg32 sourcefds(.clk_i(clk_i),.D(internal2),.Q(thebus));
   (* RLOC = "X60Y0" *) rloc_reg32 destfds(.clk_i(clk_i),.D(thebus),.Q(internal4));

And rloc_reg32 looks like this:

module rloc_reg32(input clk_i,
                  input [31:0] D,
                  output [31:0] Q);
   (* RLOC = "X0Y0"  *) FD fd00(.C(clk_i),.D(D[ 0]),.Q(Q[ 0]));
   (* RLOC = "X0Y0"  *) FD fd01(.C(clk_i),.D(D[ 1]),.Q(Q[ 1]));
   (* RLOC = "X2Y0"  *) FD fd02(.C(clk_i),.D(D[ 2]),.Q(Q[ 2]));
   (* RLOC = "X2Y0"  *) FD fd03(.C(clk_i),.D(D[ 3]),.Q(Q[ 3]));
   (* RLOC = "X0Y2"  *) FD fd04(.C(clk_i),.D(D[ 4]),.Q(Q[ 4]));
   (* RLOC = "X0Y2"  *) FD fd05(.C(clk_i),.D(D[ 5]),.Q(Q[ 5]));
   (* RLOC = "X2Y2"  *) FD fd06(.C(clk_i),.D(D[ 6]),.Q(Q[ 6]));
   (* RLOC = "X2Y2"  *) FD fd07(.C(clk_i),.D(D[ 7]),.Q(Q[ 7]));
   (* RLOC = "X0Y4"  *) FD fd08(.C(clk_i),.D(D[ 8]),.Q(Q[ 8]));
   (* RLOC = "X0Y4"  *) FD fd09(.C(clk_i),.D(D[ 9]),.Q(Q[ 9]));
   // And so on...
   (* RLOC = "X0Y14" *) FD fd28(.C(clk_i),.D(D[28]),.Q(Q[28]));
   (* RLOC = "X0Y14" *) FD fd29(.C(clk_i),.D(D[29]),.Q(Q[29]));
   (* RLOC = "X2Y14" *) FD fd30(.C(clk_i),.D(D[30]),.Q(Q[30]));
   (* RLOC = "X2Y14" *) FD fd31(.C(clk_i),.D(D[31]),.Q(Q[31]));
endmodule // rloc_reg32


Basically, I expect that I should be able to get two columns
of CLBs with each CLB containing two flip flops.

However, if I look at the design the flip flops in "destfds"
are not placed as I expect them to be. I have a screenshot
of the placed design at http://www.da.isy.liu.se/~ehliar/priv/rloc.png .
As you can see, the rloc_reg32 instance in the right has one CLB
between the columns of flip flops whereas the instance to the left
has no CLB between the columns of flip flops.

Have I misunderstood something about RLOC? I have tried to search the
answer database at xilinx.com but haven't found anything which 
explains this. (I'm using ISE 8.1 if that matters.)

/Andreas

Article: 108161
Subject: Re: Forth-CPU design
From: "J Thomas" <jethomas5@gmail.com>
Date: 6 Sep 2006 04:40:13 -0700
Links: << >>  << T >>  << A >>

rickman wrote:

> Yes, there are few advantages to a Gray code counter.  But one is a
> lower power consumption because only one bit changes on each increment.
>  Again this is unlikely to be noticed in a real chip given the small
> size of the counter.

If you're getting your code from offchip, and you need a new address
every time you get a new instruction, then the power consumption
advantage might add up, right?

To my way of thinking this is a braindead way to get code to a
processor, but it seems to be standard.


Article: 108162
Subject: Re: Forth-CPU design
From: "rickman" <gnuarm@gmail.com>
Date: 6 Sep 2006 04:54:29 -0700
Links: << >>  << T >>  << A >>
J Thomas wrote:
> rickman wrote:
>
> > Yes, there are few advantages to a Gray code counter.  But one is a
> > lower power consumption because only one bit changes on each increment.
> >  Again this is unlikely to be noticed in a real chip given the small
> > size of the counter.
>
> If you're getting your code from offchip, and you need a new address
> every time you get a new instruction, then the power consumption
> advantage might add up, right?
>
> To my way of thinking this is a braindead way to get code to a
> processor, but it seems to be standard.

Maybe I misunderstood.  I thought we were discussing addressing a
hardware stack memory.  A stack can often be just 6 bits or less.  At
that size the power difference would be virtually unmeasureable.  Off
chip sequential accesses could be a different story, but then you only
need a one bit address bus to indicate, up or down and put the counter
elsewhere.  As long as you are doing custom chips, why not optimize the
whole thing?


Article: 108163
Subject: Re: RLOC problems
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Wed, 6 Sep 2006 11:58:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2006-09-06, Andreas Ehliar <ehliar@lysator.liu.se> wrote:
> However, if I look at the design the flip flops in "destfds"
> are not placed as I expect them to be. I have a screenshot
> of the placed design at http://www.da.isy.liu.se/~ehliar/priv/rloc.png .
> As you can see, the rloc_reg32 instance in the right has one CLB
> between the columns of flip flops whereas the instance to the left
> has no CLB between the columns of flip flops.

I now noticed that I got the following error when opening the design
in the FPGA editor:

ERROR:Place:346 - The components related to The RPM "hset" can not be placed in the required relative placement form

The following components are part of this structure:
   SLICEL thebus<1>, placed to site SLICE_X4Y92
   SLICEL thebus<5>, placed to site SLICE_X4Y94
   SLICEL thebus<9>, placed to site SLICE_X4Y96
   SLICEL thebus<13>, placed to site SLICE_X4Y98
   SLICEL thebus<17>, placed to site SLICE_X4Y100
   SLICEL thebus<3>, placed to site SLICE_X6Y92
   SLICEL thebus<7>, placed to site SLICE_X6Y94
   SLICEL thebus<11>, placed to site SLICE_X6Y96
   SLICEL thebus<15>, placed to site SLICE_X6Y98
   SLICEL thebus<19>, placed to site SLICE_X6Y100
   SLICEL internal4<1>, placed to site SLICE_X72Y92
   SLICEL internal4<5>, placed to site SLICE_X72Y94
   SLICEL internal4<9>, placed to site SLICE_X72Y96
   SLICEL internal4<13>, placed to site SLICE_X72Y98
   SLICEL internal4<17>, placed to site SLICE_X72Y100
   SLICEL internal4<3>, placed to site SLICE_X76Y92
   SLICEL internal4<7>, placed to site SLICE_X76Y94
   SLICEL internal4<11>, placed to site SLICE_X76Y96
   SLICEL internal4<15>, placed to site SLICE_X76Y98
   SLICEL internal4<19>, placed to site SLICE_X76Y100
   SLICEL thebus<21>, placed to site SLICE_X4Y102
   SLICEL thebus<25>, placed to site SLICE_X4Y104
   SLICEL thebus<29>, placed to site SLICE_X4Y106
   SLICEL thebus<23>, placed to site SLICE_X6Y102
   SLICEL thebus<27>, placed to site SLICE_X6Y104
   SLICEL thebus<31>, placed to site SLICE_X6Y106
   SLICEL internal4<21>, placed to site SLICE_X72Y102
   SLICEL internal4<25>, placed to site SLICE_X72Y104
   SLICEL internal4<29>, placed to site SLICE_X72Y106
   SLICEL internal4<23>, placed to site SLICE_X76Y102
   SLICEL internal4<27>, placed to site SLICE_X76Y104
   SLICEL internal4<31>, placed to site SLICE_X76Y106

The reason for this issue is the following:
All of the logic associated with this structure is already placed and the relative placement of the logic violates the structure. The problem was found between the relative placement of SLICEL thebus<19> at site SLICE_X6Y100 and SLICEL internal4<1> at site SLICE_X72Y92.  


Changing the RLOC constraint to X72Y0 instead of X70Y0 in the top level
file seems to have corrected the problem. However I am kind of irritated
that I didn't seem to get any error or warning message about this
during place & route...


/Andreas

Article: 108164
Subject: Re: Qestion about the ability of synthesis
From: "radarman" <jshamlet@gmail.com>
Date: 6 Sep 2006 05:15:25 -0700
Links: << >>  << T >>  << A >>
Thomas Stanka wrote:
> Torsten Alt schrieb:
> > Another thing is that i would try to avoid to compare values with
> > "greater " or "lower" than a value. This can increase your logic since
> > the synthesizer has to synthesize all this cases. In your case i would
>
> I disagree. Using '=' for counters may decrease your logic but may also
> increase your logic[1]. But it will always be a pitfall, if your
> counter value gets over (for inc-counter, else under)) the value your
> looking for, due to any reason.
> I just had to remove a bug from a co-designer basing on this pitfall.
>
> For a simple counter there are only external reasons like SEU that will
> lead to this pitfall, in complex designs, there might be a erroneous
> written if-then-else path leading to the situation were your counter
> waits forever.
>
> bye Thomas
>
> [1] A 8 bit '=' needs 15 XOR2. A 8 bit '> 127'  is free in terms of
> gates.

Having seen almost every error one can make with counters, I prefer
free-running counters with reload logic. This implies that the counter
can never get "stuck". If, for some reason, the counter manages to
enter an illegal state, it will self-correct. This usually implies that
at least a small period will be garbage, but the system won't fail.

Also, while it sometimes it does make sense to make a counter 1 bit
wider than the actual count, and use the MSB as a reload signal, you
have to be careful. If you exceed the maximum length of a carry chain,
the P&R tools will break the counter up, and you may lose more
performance than if you had made the counter the exact width.

Of course, with most of my designs the reload value is never a power of
2, or the counter is under software control, so I typically write them
the "normal" way anyway.


Article: 108165
Subject: Re: Forth-CPU design
From: "J Thomas" <jethomas5@gmail.com>
Date: 6 Sep 2006 05:24:22 -0700
Links: << >>  << T >>  << A >>

rickman wrote:
> J Thomas wrote:
> > rickman wrote:
> >
> > > Yes, there are few advantages to a Gray code counter.  But one is a
> > > lower power consumption because only one bit changes on each increment.
> > >  Again this is unlikely to be noticed in a real chip given the small
> > > size of the counter.
> >
> > If you're getting your code from offchip, and you need a new address
> > every time you get a new instruction, then the power consumption
> > advantage might add up, right?
> >
> > To my way of thinking this is a braindead way to get code to a
> > processor, but it seems to be standard.
>
> Maybe I misunderstood.  I thought we were discussing addressing a
> hardware stack memory.  A stack can often be just 6 bits or less.  At
> that size the power difference would be virtually unmeasureable.  Off
> chip sequential accesses could be a different story, but then you only
> need a one bit address bus to indicate, up or down and put the counter
> elsewhere.  As long as you are doing custom chips, why not optimize the
> whole thing?

Agreed. I'm saying what you're saying.


Article: 108166
Subject: Global constants definition problem
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 6 Sep 2006 05:27:29 -0700
Links: << >>  << T >>  << A >>
Hi,
Help is needed.

I have some global constants shared among several modules, so I
set up a file to define a global package like the following:

Package MG_x_Constant is
	constant	DATA_BITS		: integer 	:= 16;
	constant DATA_RANGE		: real 		:= (2.0**16);
--	constant	DATA_BITS		: integer 	:= 64;
--	constant DATA_RANGE		: real 		:= (2.0**64);


	-- used in all test bench
	constant	DATABITS			: integer := DATA_BITS;

end MG_x_Constant;

Package body MG_x_Constant is
...
end MG_x_Constant;

In other modules, DATA_BITS, DATABITS are freely used.

This morning I found a problem:
when I changed DATA_BITS from 16 to 64, the ModelSim
sim window still shows constant DATABITS = 16 and it never changed,
even though I tried to delete the module from library and
re-compile it again. constant DATABITS = 16 doesn't change.

IN compilation order, the global package definition file is always the
first one.

I though if the global constant definition changes, all its appearance
should change, but it doesn't. Why?

What is wrong with the above statements?

Thank you.

Weng


Article: 108167
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 6 Sep 2006 05:31:00 -0700
Links: << >>  << T >>  << A >>
On Linux the only test I did was using VmWare with direct I/O access
(actually ppdev didn't work for me, it said PPEXCL  failed).

Did you try to use with DIRECT_IO?

There is a cablehost directory under src. You can patch that to connect
to server and send some messages. I've used it to connet tit to the
Xilinx CableServer and figure out what the different write modes meant

Zoltan

PS:
This weeken I'll try to more Linux testing.

Uwe Bonnes wrote:
> zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> > Hi All,
>
> > Here is a open-source CableServer replacement for Xilinx Impact.
> > Currently Parallel III and Altera ByteBlaster are supported, but any
> > 3rd party programmer cable can be implemented easily and can be used
> > from Impact. This open-source implementation can be used as a
> > Programmer Cable SDK for Impact.
>
> > I've tested only Impact 8.2, if anybody has any problem with 7.1,
> > please let me know!
>
> > Impact and Xilinx CableServer communication are very pooly written.
> > There is no error recovery at all. If server stops, Impact GUI will
> > crash. To avoid this you must disconnect server from GUI using
> > Output/Cavble disconnect menu.
>
> > http://sourceforge.net/projects/xilprg
> > http://sourceforge.net/project/showfiles.php?\
> group_id=175344&package_id=203209
> I am trying to run cblsrv on Linux (Suse10.0) with a dlc5 clone (selfmade).
> Impact with windrvr recognizes the chain.
> cblsrv -d3 -cdlc5:/dev/parport0 -p 2000 doesn't find the chain.
> Obviosly PARPORT_DIRECT needs to get undefined with PARPORT_PPDEV
> --- cblsrv-0.1/src/parport.h~   2006-09-06 07:36:08.000000000 +0200
> +++ cblsrv-0.1/src/parport.h    2006-09-06 10:35:16.000000000 +0200
> @@ -50,6 +50,7 @@
>
>  // Define this if you want to support parport access by /dev/parportX
>  #if !defined(WIN32) && !defined(__CYGWIN__)
> +#undef  PARPORT_DIRECT
>  #define PARPORT_PPDEV
>  #endif
>
> Running as root with direct io works.
>
> After the patch, running with PARPORT_PPDEV and reading the ID results in a
> crash of cblsrc:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> 306             tdi_byte = *pw++;
> (gdb) p pw
> $1 = (u8 *) 0x8070000 <Address 0x8070000 out of bounds>
> (gdb) bt
> #0  0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> #1  0x0804aedb in cable::write (this=0x804f008, mode=64, wbuff=@0xbf8fea68,
>     cmp_rbuff=@0xbf8fea50) at cable.cpp:345
> #2  0x080499db in do_cmd_write () at cblsrv.cpp:258
> #3  0x08049f26 in do_msg_commands () at cblsrv.cpp:447
> #4  0x0804a35a in client_connection () at cblsrv.cpp:584
> #5  0x0804a53a in main (argc=5, argv=0xbf8feb84) at cblsrv.cpp:800
>
> num-bit seems a little off.
>
> Any ideas? Otherwise I'll try to debug in the next days.
>
> B.t.w.: Do you have some smaller test client. Starting impact and clicking a
> zillion time to get to some point in the jtag handling is tedious...
>
>
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 108168
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 6 Sep 2006 05:38:53 -0700
Links: << >>  << T >>  << A >>
>>Running as root with direct io works.
ok, you tried it :)

I guess you have a little-endian environment (because directio works).
The current version is definetely not big-endian friendly.

Uwe Bonnes wrote:
> zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> > Hi All,
>
> > Here is a open-source CableServer replacement for Xilinx Impact.
> > Currently Parallel III and Altera ByteBlaster are supported, but any
> > 3rd party programmer cable can be implemented easily and can be used
> > from Impact. This open-source implementation can be used as a
> > Programmer Cable SDK for Impact.
>
> > I've tested only Impact 8.2, if anybody has any problem with 7.1,
> > please let me know!
>
> > Impact and Xilinx CableServer communication are very pooly written.
> > There is no error recovery at all. If server stops, Impact GUI will
> > crash. To avoid this you must disconnect server from GUI using
> > Output/Cavble disconnect menu.
>
> > http://sourceforge.net/projects/xilprg
> > http://sourceforge.net/project/showfiles.php?\
> group_id=175344&package_id=203209
> I am trying to run cblsrv on Linux (Suse10.0) with a dlc5 clone (selfmade).
> Impact with windrvr recognizes the chain.
> cblsrv -d3 -cdlc5:/dev/parport0 -p 2000 doesn't find the chain.
> Obviosly PARPORT_DIRECT needs to get undefined with PARPORT_PPDEV
> --- cblsrv-0.1/src/parport.h~   2006-09-06 07:36:08.000000000 +0200
> +++ cblsrv-0.1/src/parport.h    2006-09-06 10:35:16.000000000 +0200
> @@ -50,6 +50,7 @@
>
>  // Define this if you want to support parport access by /dev/parportX
>  #if !defined(WIN32) && !defined(__CYGWIN__)
> +#undef  PARPORT_DIRECT
>  #define PARPORT_PPDEV
>  #endif
>
> Running as root with direct io works.
>
> After the patch, running with PARPORT_PPDEV and reading the ID results in a
> crash of cblsrc:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> 306             tdi_byte = *pw++;
> (gdb) p pw
> $1 = (u8 *) 0x8070000 <Address 0x8070000 out of bounds>
> (gdb) bt
> #0  0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> #1  0x0804aedb in cable::write (this=0x804f008, mode=64, wbuff=@0xbf8fea68,
>     cmp_rbuff=@0xbf8fea50) at cable.cpp:345
> #2  0x080499db in do_cmd_write () at cblsrv.cpp:258
> #3  0x08049f26 in do_msg_commands () at cblsrv.cpp:447
> #4  0x0804a35a in client_connection () at cblsrv.cpp:584
> #5  0x0804a53a in main (argc=5, argv=0xbf8feb84) at cblsrv.cpp:800
>
> num-bit seems a little off.
>
> Any ideas? Otherwise I'll try to debug in the next days.
>
> B.t.w.: Do you have some smaller test client. Starting impact and clicking a
> zillion time to get to some point in the jtag handling is tedious...
>
>
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 108169
Subject: Re: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 6 Sep 2006 06:09:10 -0700
Links: << >>  << T >>  << A >>
I think I found the problem.

in parport::get_status:

-return ioctl(fd, PPRSTATUS);
+{
+        u8 data = 0;
+        ioctl(fd, PPRSTATUS, &data);
+        return data;
+}

Let me know if it helps!

Zoltan

Uwe Bonnes wrote:
> zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote:
> > Hi All,
>
> > Here is a open-source CableServer replacement for Xilinx Impact.
> > Currently Parallel III and Altera ByteBlaster are supported, but any
> > 3rd party programmer cable can be implemented easily and can be used
> > from Impact. This open-source implementation can be used as a
> > Programmer Cable SDK for Impact.
>
> > I've tested only Impact 8.2, if anybody has any problem with 7.1,
> > please let me know!
>
> > Impact and Xilinx CableServer communication are very pooly written.
> > There is no error recovery at all. If server stops, Impact GUI will
> > crash. To avoid this you must disconnect server from GUI using
> > Output/Cavble disconnect menu.
>
> > http://sourceforge.net/projects/xilprg
> > http://sourceforge.net/project/showfiles.php?\
> group_id=175344&package_id=203209
> I am trying to run cblsrv on Linux (Suse10.0) with a dlc5 clone (selfmade).
> Impact with windrvr recognizes the chain.
> cblsrv -d3 -cdlc5:/dev/parport0 -p 2000 doesn't find the chain.
> Obviosly PARPORT_DIRECT needs to get undefined with PARPORT_PPDEV
> --- cblsrv-0.1/src/parport.h~   2006-09-06 07:36:08.000000000 +0200
> +++ cblsrv-0.1/src/parport.h    2006-09-06 10:35:16.000000000 +0200
> @@ -50,6 +50,7 @@
>
>  // Define this if you want to support parport access by /dev/parportX
>  #if !defined(WIN32) && !defined(__CYGWIN__)
> +#undef  PARPORT_DIRECT
>  #define PARPORT_PPDEV
>  #endif
>
> Running as root with direct io works.
>
> After the patch, running with PARPORT_PPDEV and reading the ID results in a
> crash of cblsrc:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> 306             tdi_byte = *pw++;
> (gdb) p pw
> $1 = (u8 *) 0x8070000 <Address 0x8070000 out of bounds>
> (gdb) bt
> #0  0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672,
>     wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306
> #1  0x0804aedb in cable::write (this=0x804f008, mode=64, wbuff=@0xbf8fea68,
>     cmp_rbuff=@0xbf8fea50) at cable.cpp:345
> #2  0x080499db in do_cmd_write () at cblsrv.cpp:258
> #3  0x08049f26 in do_msg_commands () at cblsrv.cpp:447
> #4  0x0804a35a in client_connection () at cblsrv.cpp:584
> #5  0x0804a53a in main (argc=5, argv=0xbf8feb84) at cblsrv.cpp:800
>
> num-bit seems a little off.
>
> Any ideas? Otherwise I'll try to debug in the next days.
>
> B.t.w.: Do you have some smaller test client. Starting impact and clicking a
> zillion time to get to some point in the jtag handling is tedious...
>
>
> --
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


Article: 108170
Subject: Re: Global constants definition problem
From: "Jozsef" <bit_vector@tvn.hu>
Date: 6 Sep 2006 06:10:04 -0700
Links: << >>  << T >>  << A >>
Hello,
 Try to recompile ALL sources which references to this package. I think
about modelsim don't check & update referenced variables under
compilation process in other sources.

Best regards

Weng Tianxiang wrote:
> Hi,
> Help is needed.
>
> I have some global constants shared among several modules, so I
> set up a file to define a global package like the following:
>
> Package MG_x_Constant is
> 	constant	DATA_BITS		: integer 	:= 16;
> 	constant DATA_RANGE		: real 		:= (2.0**16);
> --	constant	DATA_BITS		: integer 	:= 64;
> --	constant DATA_RANGE		: real 		:= (2.0**64);
>
>
> 	-- used in all test bench
> 	constant	DATABITS			: integer := DATA_BITS;
>
> end MG_x_Constant;
>
> Package body MG_x_Constant is
> ...
> end MG_x_Constant;
>
> In other modules, DATA_BITS, DATABITS are freely used.
>
> This morning I found a problem:
> when I changed DATA_BITS from 16 to 64, the ModelSim
> sim window still shows constant DATABITS = 16 and it never changed,
> even though I tried to delete the module from library and
> re-compile it again. constant DATABITS = 16 doesn't change.
>
> IN compilation order, the global package definition file is always the
> first one.
>
> I though if the global constant definition changes, all its appearance
> should change, but it doesn't. Why?
> 
> What is wrong with the above statements?
> 
> Thank you.
> 
> Weng


Article: 108171
Subject: How to bound a Cores generated output in Modelsim
From: "fl" <rxjwg98@gmail.com>
Date: 6 Sep 2006 07:09:52 -0700
Links: << >>  << T >>  << A >>
Hi,
I am learning Xilinx ISE Webpack 8.2. There is an example watchvhd.ise
in the package. The component tenths is generated from Cores utility.
When I go to Modelsim to do behavioral simulation. It says:

# -- Compiling entity testbench
# -- Compiling architecture testbench_arch of testbench
# vsim -lib work -t 1ps testbench
# Loading C:\Modeltech_xe_starter\win32xoem/../std.standard
# Loading
C:\Modeltech_xe_starter\win32xoem/../ieee.std_logic_1164(body)
# Loading C:\Modeltech_xe_starter\win32xoem/../std.textio(body)
# Loading
C:\Modeltech_xe_starter\win32xoem/../ieee.std_logic_textio(body)
# Loading work.testbench(testbench_arch)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.vcomponents
# Loading work.stopwatch(inside)
# Loading work.statmach(behavior)
# Loading C:\Modeltech_xe_starter\win32xoem/../ieee.numeric_std(body)
# Loading work.dcm1(behavioral)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.ibufg(ibufg_v)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.bufg(bufg_v)
# Loading C:\Modeltech_xe_starter\win32xoem/../ieee.vital_timing(body)
# Loading
C:\Modeltech_xe_starter\win32xoem/../ieee.vital_primitives(body)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.vpkg(body)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.dcm(dcm_v)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.dcm_clock_divide_by_2(dcm_clock_divide_by_2_v)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.dcm_maximum_period_check(dcm_maximum_period_check_v)
# Loading
C:\Modeltech_xe_starter\win32xoem/../xilinx/vhdl/unisim.dcm_clock_lost(dcm_clock_lost_v)
# ** Warning: (vsim-3473) Component instance "xcounter : tenths" is not
bound.
#    Time: 0 ps  Iteration: 0  Region: /testbench/uut  File:
stopwatch.vhd
# Loading
C:\Modeltech_xe_starter\win32xoem/../ieee.std_logic_arith(body)
# Loading
C:\Modeltech_xe_starter\win32xoem/../ieee.std_logic_unsigned(body)
# Loading work.decode(behavioral)
# Loading work.cnt60(inside)
# Loading C:\Modeltech_xe_starter\win32xoem/../synopsys.attributes
# Loading
C:\Modeltech_xe_starter\win32xoem/../ieee.std_logic_misc(body)
# Loading work.smallcntr(inside)
# Loading work.hex2led(behavioral)
# .main_pane.mdi.interior.cs.vm.paneset.cli_0.wf.clip.cs.pw.wf
# .main_pane.workspace
# .main_pane.signals.interior.cs

I have browsed the group. tenths.vho file is in the directory. How
modelsim to bound it in simulation? Thanks you.


Article: 108172
Subject: Re: fastest FPGA
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Sep 2006 10:43:25 -0400
Links: << >>  << T >>  << A >>
rickman wrote:

> Can you use the SRL as a FIFO?  I was not aware that you could change
> the length.  I thought that was a configuration setting.  If they are
> doing that the only extra for the moving pointers would be the 4 bit
> write address counter.
> 

YOu sure can.  I think a synchronous fifo was the very first macro I 
wrote for the SRL16, before I could even get a part with them in it.

To use it as a FIFO, you use an SRL16 (or several in parallel for 
multi-bit) plus an up-down counter.  Push activates the SRL16's write 
enable and increments the count.  Pop just decrements the count.  The 
count addresses the SRL16 read port.  If you make the counter 5 bits and 
preload it with "11111" then you get an empty indication from the 
counter's msb for almost free.

Article: 108173
Subject: Re: fastest FPGA
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Sep 2006 10:54:43 -0400
Links: << >>  << T >>  << A >>
John_H wrote:


> The up/down count takes more than one level of logic but it sure is 
> quick & easy to code.  It infers pretty well as long as you don't try to 
> add a reset to the mix.  The register coupled to the LUT in the slice 
> also has an enable that can be different than the write enable (shift 
> enable) allowing a little more flexibility.
> 
> Although the early SRLs were a bit slower than one might want in-system, 
> the current generation of Spartan devices - as I've been assured by the 
> Xilinx support folks - can reach the full speed of the device if you use 
> the slice register from the LUT/SRL output.

Up-down count doesn't have to take two levels of logic, it can be done 
with one level, but it has to be specified carefully to keep the 
synthesis from making it into two levels.  Reset works fine too:

signa cnt, cnt_dec: unsigned(4 downto 0);
signal cnt_inc: integer range 0 to 1;

cnt_dec <= to_unsigned(-1,5) when pop='1' else (others=>'0');
cnt_inc <= 1 when push='1' else 0;

process(clk)
if rising_edge(clk) then
    if reset ='1' then
	cnt <= (others=>'1');
    else
	cnt <= cnt + cnt_dec + cnt_inc;
    end if;
end if;

Also, the SRL16's are as fast as the rest of the logic IF you use the 
flip-flop on the output.  They are dreadfully slow if you route out 
combinatorially in the older families.  They've always been fast enough 
to use with the output flip-flops...faster than a 16 bit carry chain anyway.


Article: 108174
Subject: Re: Global constants definition problem
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 6 Sep 2006 08:07:21 -0700
Links: << >>  << T >>  << A >>

Jozsef wrote:
> Hello,
>  Try to recompile ALL sources which references to this package. I think
> about modelsim don't check & update referenced variables under
> compilation process in other sources.
>
> Best regards
>
> Weng Tianxiang wrote:
> > Hi,
> > Help is needed.
> >
> > I have some global constants shared among several modules, so I
> > set up a file to define a global package like the following:
> >
> > Package MG_x_Constant is
> > 	constant	DATA_BITS		: integer 	:= 16;
> > 	constant DATA_RANGE		: real 		:= (2.0**16);
> > --	constant	DATA_BITS		: integer 	:= 64;
> > --	constant DATA_RANGE		: real 		:= (2.0**64);
> >
> >
> > 	-- used in all test bench
> > 	constant	DATABITS			: integer := DATA_BITS;
> >
> > end MG_x_Constant;
> >
> > Package body MG_x_Constant is
> > ...
> > end MG_x_Constant;
> >
> > In other modules, DATA_BITS, DATABITS are freely used.
> >
> > This morning I found a problem:
> > when I changed DATA_BITS from 16 to 64, the ModelSim
> > sim window still shows constant DATABITS = 16 and it never changed,
> > even though I tried to delete the module from library and
> > re-compile it again. constant DATABITS = 16 doesn't change.
> >
> > IN compilation order, the global package definition file is always the
> > first one.
> >
> > I though if the global constant definition changes, all its appearance
> > should change, but it doesn't. Why?
> >
> > What is wrong with the above statements?
> >
> > Thank you.
> >
> > Weng

Hi Jozsef,
I re-compiled every modules, but the constants in global package don't
change as if they were compiled once and never re-compiled again.

I even deleted all work directory contents, recompile every modules,
but constants in the global package still don't change.

That is what I have experienced.

Any other ideas?

Weng




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