Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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! AnttiArticle: 108151
Hello. Do anybody have ORCAD library for Xilinx xc3s1500 in FG320 package and TI TMS320C6713BGDP300? Thanks, Dmitry.Article: 108152
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=E9Article: 108153
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! AnttiArticle: 108154
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
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
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: 108157Uwe 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
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
@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
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: 108161rickman 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
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
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... /AndreasArticle: 108164
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
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
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. WengArticle: 108167
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
>>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
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: 108170Hello, 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. > > WengArticle: 108171
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
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
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: 108174Jozsef 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:
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