simplyrisc-s1 free core

Jan Panteltje schrieb:

I am trying it right now - seems like lot of fun, when trying it with Xilinx ISE it has already managed to make 3 different kinds of fatal crashes !!

so it would be good test case for Xilinx to test their software against.

Antti

And how exactly this is different from any other large design? :-)

Jon Beniston schrieb:

you said it :)

well the only difference is that this is the one large design I would like to get going right now. hm.. the other last largish design I also have interest is the OpenRisc1000 - that one does not crash but it terminates the build saying that 1GB RAM is not enough !

so it can be that the only large designs that do not crash are those that Xilinx is using for ISE harness testing.

Antti

That is rather odd because I have successfully synthesized a system containing an or1200, an sdram controller, a vga controller and some other peripherals on a machine with 512MB RAM. Probably using ISE 7.1 IIRC. (Nowadays I have more memory in the machine though...)

Did you define SYNTHESIZE and the correct XILINX defines in or1200_defines.v? Otherwise I know that the synthesis will run for longer than I care to wait...

/Andreas

Andreas Ehliar schrieb:

? I did take the ORP thing from opencores and have tried to define everthing out to make the minimal possible system, but all I get is

ERROR:Portability:3 - This Xilinx application has run out of memory or has encountered a memory conflict. Current memory usage is 2091920 kb.

BTW there is no SYNTHESIZE thing in the or1200_defines.v :( there is something about xilinx memories and the synthese really uses xilinx RAMB16 prims, but what else to check I dont know.

it simply runs out of memory, well its 8.1 SP3, maybe it works on 7.1 ??

Antti

Oops, I think I should be a bit embarrased. I guess that we added it to our version of or1200 used in teaching. `include "shamed_face.v" I guess :) Sorry for making you look for something which wasn't there.

Anyway, what I can confirm is that we have successfully synthesized an older version of OR1200 with both ISE 7.1 and 8.1. The exact version can be found on the course homepage at

Lab1 is a small system with the UART and parport missing (the students are supposed to implement those to get familiar with wishbone and verilog) whereas lab2-4 is a larger system. It should be possible to trim it down to a smaller system if necessary.

/Andreas

Hi Andreas,

In article , ehliar@lysator

How much of the resources are used by the OR1200? Can you fit the OR1200, an SDRAM controller and the Ethernet in there?

Thanks. John.

Into what? We are using a XC2V4000 in this course so we can fit quite a lot. But the resource breakdown looks roughly like this after the design has been synthesized.

LUT FF

• cpu 5047 1345

• dma 654 254

• vga 816 755

• eth 2965 2337

• dct accelerator 1680 679

• camera 518 527

• sram controller 129 25

• sdram controller 187 70

• blockram controller 111 3

• UART 823 346

• wishbone bus 618 10

The resource utilization was extracted from the XDL file after synthesis, map and place and route. This means that some signals which belong to more than one module ends up in only one module after all. Some blockrams are also used but I haven't added RAMB16 extraction to my script yet.

/Andreas

Well, do you have the impression that the ISE programmers test their software and have a regression test suite?

For example they claimed the Impact crash on Linux when reloading a bitstream/jedec file fixed, obvious it wasn't, as easy test showed (Xilinx Answer #23745). Or if you look at the still unsilved VLGINCDIR problem Answer Record # 17027. It worked in some ISE 6 version, but was broken in ISE 7 again.

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

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

Uwe Bonnes schrieb:

Uwe,

Xilinx defenetly has a regresion test suite.

But in the context of their software management this only means that their software doesnt fail on the regression suite, and may fail and often does an any other design.

No matter how many bugs they fix, new bugs come or re-appear in even bigger number so the overall software quality isnt improving.

OTOH it depends on the metrics - I have one simple measurement TTFFC - time to first fatal crash (from fresh install)

ISE 8.1 - 3 minutes ISE 8.2 - 8 minutes

so by that metrics we have ISE 8.2 software quality improved by 250% over ISE 8.1 so it all depends :)

and to Xilinx, yes please take this seriously.

Antti