Xilinx 3s8000?

All well and good, unless you work in a company that refuses to
actually purchase PC's. When they go EOL (end of lease) that's it -
they disappear one night never to be seen again. (the IT dept is nice
enough to copy everything in your user folder to the new hard disk,
though)

We are still fighting to keep an old P3 system that went EOL years ago,
and that we are presumably paying penalties on, because it is the last
system with a working copy of several packages we need that are no
longer supported. It's kind of sad to see so many developers sharing
time on what has to be the oldest PC in the department.

Of course,  there are always those unsuspecting lab machines that
haven't ever had design tools installed on them...

In article <1147203980.950132.150410@e56g2000cwe.googlegroups.com>,
Jeff Brower <jbrower@signalogic.com> wrote:

> Radarman-
> 
> > We fought for a week with every part of the
> > toolchain until we switched to another workstation to create the
> > bitstream files - no errors, just corrupt binaries.
> 
> I don't understand the struggle.  You are violating basic usage
> principles of ISE.  Never a) uninstall and re-install, or b) install a
> new version on the same machine as an earlier working version.  The
> only thing permitted on any given machine is service pack upgrades
> within a version.  Yes that leaves you with the "5.1 machine", the "6.1
> machine", etc. but that's the rule.  Your FAE should have told you
> that; it's all we've ever heard since 1999 and several different FAEs.

Is that a licensing thing or a functionality thing?

When I got my Spartan 3e starter kit a few days ago, I installed the
included ISE 8.1 under E:\Program Files\Xilinx .

When I found out that some things Do Not Work in paths that have spaces
in them, I uninstalled it and re-installed it under
E:\ProgramFiles\Xilinx .

Have I set myself up for a lifetime of pain until I get a new computer?

-- 
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)

> Would a VM like VMWare or VPC do the trick, keep your OS with ISE
> version installed in different virtual boxes. As long as only one runs
> all the machine resources are available to that VM guest, whether its
> Linux or Windows.

Do you say that this would still run at full speed?
has anyone tried this?

I suspect the emulation takes quite some ressources ...


bye,
Michael

No, it's not generally a licensing problem. It's more a problem with
lousy programming, and the different versions tripping over each other.
The software depends on environment variables instead of using the
registry for a lot of things, and depending on which is first, you can
end up calling the old version with the new version, or in my case,
vice-versa.

The sad thing is, Xilinx gets the rocket science (mapping and PAR)
right - but screws up on the little stuff. None of these problems are
endemic to Windows applications. For some reason, though, when
engineering companies release software, they always ignore the spit and
polish. Modeltech did it (and now that they are owned by Mentor
Graphics, it's even worse). Synplicity does it - particularly with that
HUGE "RUN" button and other non-standard dialogues.

You would think it would be simpler to just write a decent Windows
shell, a separate Unix shell, and then use portable C or C++ for the
core application than to maintain all that homegrown cruft. Heck,
ModelSim is actually *LESS* usable now at 6.1 than it was in 5.8!

Usability aside, though - the tools don't use standard OS features that
could help prevent these problems. Most applications use the registry
in Windows, where it is fairly simple to setup a structure that allows
for multiple versions. In Unix, it is fairly simple to keep all  your
configuration files in the same folder, and create Makefiles that call
out which tool to use.

It isn't hard. If *I* can do it, with just an average knowledge of C
and almost zero C++, I suspect the developers at most of these
engineering companies can do it as well.

=?ISO-8859-1?Q?Michael_Sch=F6berl?= (MSchoeberl@mailtonne.de) wrote:

: Do you say that this would still run at full speed?
: has anyone tried this?

: I suspect the emulation takes quite some ressources ...

Running an x86 virtual PC on an x86 host can use virtualization where most 
code (non priveledged stuff etc.) runs nativly, so there is a much less 
significant performance hit than with emulation.

You need a lot of memory though as both the host and guest OS' memory 
requirements must be fulfilled.

Also the old tools will have been used with older, slower PCs so will get 
a speed bost from the modern PC which probably offsets the virtualization 
overhead.

Where the VM aproach falls down is where you have software that is locked 
to some physical dongle...

cds

Before abandoning this thread, I thought I would cobble together a 
72*72->144 multiplier using the 3s500's built-in 18*18->36 bit hardware 
multipliers. The result is shown below. As you can see, more slices and 
LUT's are required when using the built-in hardware multipliers than by 
the same width multiplier written in pure Verilog, *but* the frequency 
is also faster.

     Device utilization summary:
     ---------------------------
     Selected Device : 3s500epq208-4
      Number of Slices:                     817  out of   4656    17%
      Number of Slice Flip Flops:           669  out of   9312     7%
      Number of 4 input LUTs:              1094  out of   9312    11%
      Number of bonded IOBs:                 18  out of    158    11%
      Number of MULT18X18s:                  16  out of     20    80%
      Number of GCLKs:                        1  out of     24     4%

     Timing Summary:
     ---------------
     Speed Grade: -4
        Minimum period: 12.982ns (Maximum Frequency: 77.033MHz)
        Minimum input arrival time before clock: 10.583ns
        Maximum output required time after clock: 8.062ns
        Maximum combinational path delay: No path found

It's a little hard to believe that the circuit design using the builtin 
multipliers actually requires more FPGA space than doing the whole thing 
in Verilog, so I've pasted the Verilog source code that I wrote to test 
the hardware multipliers into this message below. As you can see, the 
synthesizer automatically chooses to use the builtin MULT18X18s simply 
because I specified an 18*18 bit multiply in the Verilog code (see 
m36.v) without requiring me to explicitely instantiate the MULT18X18 
multipliers by name.

There are three modules. They are:
1. m36.v
2. m72.v
3. main.v

"main.v" is a simple I/O interface for MX_72 which is the main 
multiplier. The only reason for having "main" is so that the synthesizer 
won't complain about running out of I/O pins. Let me know if you're able 
to cut down on the gate count significantly. I already know I could 
probably eliminate one or two temporary registers I used in MX_72, but 
doubt it would make much difference.

Regards,

Ron


//================= m72.v =================
// m72.v, (c) May 9, 2006, Ron Dotson

module MX_72 (reset,clock,a,b,  r,finished);
parameter N=72;  // Bus Width of input
parameter L=36;  // Half the Bus Width
parameter S0=0,S1=1,S2=2,S3=3,S4=4,S5=5,S6=6,S7=7;
input       reset, clock;
input       [N-1:0] a,b;
output reg  [2*N-1:0] r;
output reg  finished;

reg         resetMX;
reg         [1:0] state;
reg         [L-1:0] a1,b1, a2,b2;
reg         [2*N-1:0] t1,t2,t3;
wire        [N-1:0] r1,r2,r3,r4;
wire        finished1,finished2,finished3,finished4;

MX_36 m1 (resetMX,clock,a1,b1,  r1,finished1);
MX_36 m2 (resetMX,clock,a1,b2,  r2,finished2);
MX_36 m3 (resetMX,clock,a2,b1,  r3,finished3);
MX_36 m4 (resetMX,clock,a2,b2,  r4,finished4);

always @(posedge clock)
if (reset==1)
     begin
     finished<= 0;
     resetMX<= 0;
     a2<= a[N-1:L];  // MSB a
     a1<= a[L-1:0];  // LSB a
     b2<= b[N-1:L];  // MSB b
     b1<= b[L-1:0];  // LSB b
     t1<= 0;
     t2<= 0;
     t3<= 0;
     state<= S0;
     end
else
     begin
     case (state)
         S0: begin
             resetMX<= 1;
             state<= S1;
             end
         S1: begin
             resetMX<= 0;
             state<= S2;
             end
         S2: begin
             if (finished1 & finished2 & finished3)
                 begin
                 t1[N-1:0]<= r1;
                 t1[2*N-1:N]<= r1[N-1]? -1: 0;  // extend sign
                 t2[2*N-1:L]<= r2 + r3;
                 t3[2*N-1:N]<= r4;
                 state<= S3;
                 end
             end
         S3: begin
             r<= t1 + t2 + t3;
             finished<= 1;
             end
     endcase
     end

endmodule

//================= m26.v =================
// m36.v, (c) May 9, 2006, Ron Dotson

module MX_36 (reset,clock,a,b,  result,finished);
parameter N=36; // Bus Width of input

input       reset, clock;
input       [N-1:0] a, b;
output reg  [2*N-1:0] result;
output reg  finished;

always @(posedge clock)
if (reset==1)
     begin
     finished<= 0;
     end
else
     begin
     result<= a*b;  // instantiates builtin h/w multiplier
     finished<= 1;
     end

endmodule

//================= main =================
// main.v, I/O interface
// (c) Jan 14, 2006, Ron Dotson

// Note: Need bus-width of 576 bits to solve "Most Wanted"
//       Cunningham numbers at:
//       http://homes.cerias.purdue.edu/~ssw/cun/want97
//
// SW2= A19(1) = resetMain    Expected  Was
// D1 = G1(7)= Led0  (~LD0)       X      X     D1
// D2 = G2(7)= Led1  (~LD1)       X      0     D2
// D3 = H1(7)= Led2               1      1     D3
// D4 = H2(7)= Led3  (Data bit 0) 1      1     D4
// D5 = J1(7)= Led4  (Data bit 1) 1      1     D5
// D6 = J2(7)= Led5  (Data bit 2) 0      0     D6
// D7 = K1(7)= Led[6]             1      1     D7
// D8 = K2(7)= Led[7]             1      1     D8

module main(resetMain,clock,Sw[7:0],  Led[7:0]);
parameter N=72;  // Bus Width of input
parameter L=36;  // Half the Bus Width
parameter S0=0,S1=1,S2=2,S3=3;
input      resetMain, clock;
input      [7:0] Sw;
output reg [7:0] Led;

reg        mReset;
reg        [1:0] state;
reg        [N-1:0] a,b;
wire       [2*N-1:0] r;             // 72*72->144
wire       finished, LD1,LD0;

MX_72 mx72 (mReset,clock,a,b,  r,finished);

always @(posedge clock)
if (~resetMain)             // SW2 = Low when pressed
     begin
     mReset<= 1;
     Led[7:0]<= -1;          // Leds OFF
     state<= S0;

//  a<= 17;  b<= 13;      // Test Case 1
//  a<= 137; b<= 223;     // Test Case 2
//  a<= 157; b<=223;      // Test Case 3
//  a<= 33013; b<= 35023; // Test Case 4

// Test Case 5
     a[ 71: 64]<= 8'hA9;
     a[ 63: 32]<= 32'h7B78BE29;
     a[ 31:  0]<= 32'h9C540469;

     b[ 71: 64]<= 8'h9B;
     b[ 63: 32]<= 32'hE4BB0E99;
     b[ 31:  0]<= 32'h19425200;
     end
else
     begin
     case (state)
     S0: begin
         mReset<= 1;
         Led[2]<=1;       // OFF
         state<= S1;
         end
     S1: begin
         if (mReset)
             mReset<= 0;
         else
             begin
             Led[2]<= ~Led[2];
             Led[0]<= ~LD0;
             Led[1]<= ~LD1;
             if (finished)
                 begin
                 state<= S2;           // Solved
                 end
             end
         end
     S2: begin
         if (Sw[7])                    // On=Up
             begin
             Led[0]<= ~LD0;            // D1
             Led[1]<= ~LD1;            // D2
             Led[2]<= 0;               // D3= ON
             Led[3]<= ~r[0]; // D4   (Data bit 0)
             Led[4]<= ~r[1]; // D5   (Data bit 1)
             Led[5]<= ~r[2]; // D6   (Data bit 2)
             Led[6]<= 0;
             Led[7]<= 0;    // finished. Turn on Led D8
             end
         else
             begin
             case (Sw[5:0])
                  0: begin
                     Led<= ~r[7:0];
                     end
                  1: begin
                     Led<= ~r[15:8];
                     end
                  2: begin
                     Led<= ~r[23:16];
                     end
                  3: begin
                     Led<= ~r[31:24];
                     end
                  4: begin
                     Led<= ~r[39:32];
                     end
                  5: begin
                     Led<= ~r[47:40];
                     end
                  6: begin
                     Led<= ~r[55:48];
                     end
                  7: begin
                     Led<= ~r[63:56];
                     end
                  8: begin
                     Led<= ~r[71:64];
                     end
                  9: begin
                     Led<= ~r[79:72];
                     end
                 10: begin
                     Led<= ~r[87:80];
                     end
                 11: begin
                     Led<= ~r[95:88];
                     end
                 12: begin
                     Led<= ~r[103:96];
                     end
                 13: begin
                     Led<= ~r[111:104];
                     end
                 14: begin
                     Led<= ~r[119:112];
                     end
                 15: begin
                     Led<= ~r[127:120];
                     end
                 16: begin
                     Led<= ~r[135:128];
                     end
                 17: begin
                     Led<= ~r[143:136];
                     end
                 default:
                    begin
                    Led<= -1;  // all OFF
                    end
             endcase
             end
         end
     endcase
     end
endmodule

radarman wrote:
> No, it's not generally a licensing problem. It's more a problem with
> lousy programming, and the different versions tripping over each other.
> The software depends on environment variables instead of using the
> registry for a lot of things, and depending on which is first, you can
> end up calling the old version with the new version, or in my case,
> vice-versa.

Or you can move the environment variables into bat files, as I did
several years back before the linux tools became usable (hosting
WebPack and ISE 4.2 on WinMe):

# cat Xilinx4K.bat
SET PATH=C:\Xilinx4K\bin\nt;%PATH%
SET XILINX=C:\Xilinx4K
C:\Xilinx4K\bin\nt\ise.exe

# cat XilinxFdn4.bat
SET PATH=C:\XilinxFdn4\bin\nt;%PATH%
SET XILINX=C:\XilinxFdn4
C:\XilinxFdn4\bin\nt\dsgnmgr.exe

I assume that is still possible today?

c d saunter wrote:
> =?ISO-8859-1?Q?Michael_Sch=F6berl?= (MSchoeberl@mailtonne.de) wrote:
>
> : Do you say that this would still run at full speed?
> : has anyone tried this?
>

No reason to try it myself, also the cost of VM servers used to be
prohibitive for play use but the VMWare scene has changed alot with
free guest VMs.

> : I suspect the emulation takes quite some ressources ...
>
> Running an x86 virtual PC on an x86 host can use virtualization where most
> code (non priveledged stuff etc.) runs nativly, so there is a much less
> significant performance hit than with emulation.
>
> You need a lot of memory though as both the host and guest OS' memory
> requirements must be fulfilled.
>

I wonder if there would be some advantage to running Windows Vm boxes
on Linux rather than on WIndows host, or vice versa for memory
advantages or to satisfy OS preference while using EDA tool with the
vendor supported OS.

> Also the old tools will have been used with older, slower PCs so will get
> a speed bost from the modern PC which probably offsets the virtualization
> overhead.
>
> Where the VM aproach falls down is where you have software that is locked
> to some physical dongle...
>

Indeed but I am sure that other VM users must be using protected
software licenses too so same solution at hand, probably network
license. Still its more work to insert another layer.

FWIW alot of VM issues get discussed on OSNews since all the vendors
are constantly in the news.

> cds

Ron,

I was cleaning out one of the labs yesterday and I came by a box topped
with much dust.  I brushed it off and came across some Xilinx devices.

XC4005-5PG156C
XCS40-3PQ208C

I immediately thought of you, as this thread has been indelibly etched
into my mind, due to all the colorful and enlightening dialogue.

I have no use for these items, and if Xilinx doesn't see anything wrong
with me giving a couple to you, I could then mail them.

Rob


Ron wrote:
> Glory and riches are showered upon those who successfully factor one of
> the RSA Challenge Numbers (see note [1]) ;-).  I would like to be the
> first to factor an RSA number using a standalone FPGA development
> board(s) (ie; not connected to a conventional computer).
>
> The RSA Challenge numbers have traditionally been solved by networks of
> supercomputers using a distributed Number Field Sieve (NFS) or similar
> method. Sieving is unfortunately not suited to FPGA implementation, but
> there is another integer factorization method called the Elliptic Curve
> Method (ECM, see note [3]) that I think might stand a chance of cracking
> RSA-704. I have therefore designed and tested a Verilog implementation
> of ECM with a compile time bus-width specification (ie; `define L 704)
> so that it's easy to determine how the LUT requirement increases as I
> change the bus width. I've optimized the circuit for gate count to the
> extent of multiplexing everything that is used more than once (multiply,
> divide, modulo, etc) - a process that almost brought tears to my eyes at
> one point, because I had to eliminate several areas that naturally lent
> themselves to parallelization.
>
> Even so, the design requires far more LUTs than are currently available
> from anyone as far as I know. I presently have Xilinx xc3s500e and Actel
> ProASIC3E A3PE600 development boards, but I can't compile the design for
> a 704 bit bus-width because I get the error message in Note [4] below (I
> also get a similar message from the Actel synthesizer). I *can* compile
> the design for a 384 bus-width however. Using a Xilinx 3s4000 as the
> target device (even though I only have a 3s500) with a 384 bit
> bus-width, I get the following Device utilization summary:
>      ---------------------------
>      Selected Device : 3s4000fg676-4
>       Number of Slices:                   49176  out of  27648   177% (*)
>       Number of Slice Flip Flops:         52253  out of  55296    94%
>       Number of 4 input LUTs:             83797  out of  55296   151% (*)
>       Number of bonded IOBs:                 18  out of    489     3%
>       Number of GCLKs:                        1  out of      8    12%
>      WARNING:Xst:1336 -  (*) More than 100% of Device resources are used
>      ---------------------------
>
>
> This would lead me to believe that my design would require at least
> 101,376 LUTs, and probably more depending on how much of the FPGA is
> consumed by routing. Since the Xilinx 3s4000 has 55296 LUTs and 27648
> slices, I imagine a part with twice that number of slices & LUTs (a
> Xilinx 3s8000 perhaps?) would be needed to fit my design. Anyone care to
> hazard a guess as to if/when such a monster might be available?
>
> Also, thus far the longest number that has been factored with ECM is
> only 66 decimal digits (see Note [3]). If RSA-704 (212 decimal digits)
> were factored, it would set a new record for ECM factoring also.
>
> If such a device did become available, my only hope for acquiring the
> requisite hardware/software would be to work out a deal with the FPGA
> vendor or someone to lend me the necessary development board and s/w
> tools in exchange for the potential fame and glory, since I am but a
> humble retired engineer/hobbyist. :-)
>
> Ron
>
>
> _________________
> Notes:
>
> [1] RSA Challenge Numbers:
> http://www.rsasecurity.com/rsalabs/node.asp?id=2093
>
> [2] Factoring Methods:
> http://mathworld.wolfram.com/PrimeFactorizationAlgorithms.html
>
> [3] Elliptic Curve Factorization Method
> http://mathworld.wolfram.com/EllipticCurveFactorizationMethod.html
>
> [4] When synthesizing ECM with a 704 bit bus-width for the Xilinx
> xc3s4000-4fg676, I get:
>
> ERROR: Portability:3 - This Xilinx application has run out of memory or
> has encountered a memory conflict.  Current memory usage is 2092148 kb.
>   Memory problems may require a simple increase in available system
> memory, or possibly a fix to the software or a special workaround.  To
> troubleshoot or remedy the problem, first:  Try increasing your system's
> RAM.  Alternatively, you may try increasing your system's virtual memory
> or swap space.  If this does not fix the problem, please try the
> following:  Search the Answers Database at support.xilinx.com to locate
> information on this error message.  If neither of the above resources
> produces an available solution, please use Web Support to open a case
> with Xilinx Technical Support off of support.xilinx.com.  As it is
> likely that this may be an unforeseen problem, please be prepared to
> submit relevant design files if necessary.
> ERROR: XST failed
> Process "Synthesize" did not complete.

robnstef@frontiernet.net wrote:
> I have no use for these items, and if Xilinx doesn't see anything wrong
> with me giving a couple to you, I could then mail them.

I sincerely appreciate the offer Rob, but unless I'm missing something 
the devices you mention are older and consequently smaller devices than 
I really need. I'm looking to target one of the larger vendors devices 
on a hobbyist budget, and my primary obstacle is the high cost of the 
design software rather than the FPGAs and development boards themselves. 
Thanks to John Bass's earlier suggestion about ebay, the cost of the 
hardware is no longer much of an issue, but if you ever happen to run 
across an old dusty box labeled "Xilinx ISE Foundation," "Actel Libero 
Platninum", "Altera Quartus II Standard Edition," or even Lattice 
Semiconductor's full version of ispLEVER that hasn't yet been 
"activated", I would surely appreciate a copy of it.

Regards,

Ron