New Lattice 32-bit Embedded Microprocessor Available Through Unique Open Source License

Is this not a Verilog 2001 feature that isn't supported?

Cheers, Jon

I don't understand the idea of using post syn timing. Is that at all accurate? Why not let it do a PAR and see what kind of real results you get? I guess I shouldn't knock post syn timing. The eval I did on my CPU gave pretty close numbers between syn and PAR. I think it actually sped up a little in PAR.

Sometimes it is close, sometimes it is woefully inaccurate.

It's the only way to know.

Cheers, Jon

True - and as soon as I know you will know! - I left it PARing as I left the office, and won't see the result myself until I am back monday. However, from the post MAP timing, it looked good. I also put a clock constraint of 200MHz on it (just to see). I'm curious myself. I think the result would be more useful if I included a few more of the core features, like debug logic, jtag, multiplier support etc. I just left it with the defaults.

Regarding the verilog2001 support - XST seems to have clogb2 support, but just there seemed to be some restrictions on where it can be used - it could be because the RTL code is using it in a way that violates the strict rules on the LRM, or it could be XST simply needs to allow the use of this function more liberally (like in a preprocessing function when reading the RTL, as its used as a constant), who knows. All I know is it was not much effort to make it work, so hardly makes XST unsable for synthesis of this core. This info mught help a few people out who do not have access to alternatives....but if you really want to knock synthesizers..check out design compiler in an asic context *shudder*.

John McGrath schrieb:

whah? it hasnt finished? you should have used relaxed timing constraints.

A microblaze design with all CPU options enabled and with Floating Point unit included, targetting XC3S4000 using 489 IO's and having

192KB used local memory runs within some minutes until bitstream done. (takes 14% BTW from s3-4000)

I bet your LM32 test desing is far less complex

getting 200MHz in slowest speed V5 seems unlikely, OpenFire demo design did pass 200MHz in fastest V5 after a few xplorer runs.

so I bet the LatticeMico32 want pass timing on 200Mhz Antti

Sometimes overconstraining the design too much will mean the tool will give up earlier than it otherwise would if it was quite close, or so I've been led to believe.

The JTAG logic requires Lattice specific cells, so you wouldn't be able to use that, unless you converted it to work with the Xilinx JTAG primitive.

clogb2 is a function defined in the Mico32 source.

I do :-) XST doesn't support Verilog 2001 constant functions, which is what is being used here.

Cheers, Jon

Perhaps a bit off topic, but I use Google to access these newsgroups and this thread is not displaying properly. Instead of showing a post number beside each post in the tree to the left, it puts the number 1 beside each one. That makes it very hard to see just which post is which in the thread.

Does anyone else see this or is it just me?

I see it too. A problem shared is a problem halved?

Same here, weird..

-Isaac

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Well, as some people used to jest at the height of the "intel inside" logo campaign: how's that for a problem neatly encircled.

As well as Google knows how to do a web search engine, as bad is their grasp of Usenet. They're arguably the biggest threat to Usenet's continuing existence since "the September that never ended".

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

How so? I'm unfamiliar with google's approach, can you go into more detail?

-Dave

--
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

I used google for "the september that never ended" and found

and learned a new term I didn't know before.

Doom and gloom! I think things will turn out ok. :)

-Dave

--
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

To highlight just a few of the worst points:

0) a posting mechanism that makes it effectively impossible for the average user to quote at all, and

1) once they found out how to get it to quote at all, quotes as badly as OE, but at least OE can be patched to fix the worst mistakes.

2) has just about the most broken threading on the planet

3) mixing actual Usenet newsgroups and Google's own web forums in a single user interface, without so much as bothering to *mention* that there are both technical and cultural differences between the two.

In the net effect, Google Groups took all the worst aspects of web forum "culture", and ported them back to Usenet.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

It's no different than ANY provider who w>To highlight just a few of the worst points:

Complete nonsense--and it was NEVER true. .

Yes. At one time getting context quoting was not obvious.

Google Groups is now quite usable for all but complete nit-wits.

True.

***WHAT HAPPENED TO THIS THREAD ON GOOGLE*** When the second poster to the thread used X-No-Archive, the day his post drops off, Google's indexing went to hell. (After its expiration, any posts below such a post get borked.)

True.

If they would force newbies to click thru a rules-of-the-road page BEFORE allowing them to post and come up with a more responsive abuse mechanism

--which also BLOCKS abuse-tolerant ISPs until they get their shit together, THAT would help. A page like this: http://66.102.9.104/search?q=cache:CMU1z-5ywJ4J:shopsite.com/help/4.1/sc/lte/usenet.html+rude.to.advertise.*.*+*-*-*-*-*-*-the-word-forsale-or-marketplace-in-their-names+preserve.*.culture.of.open.discussion+reads-an-advertisement+*.most.pervasive.form.*.*.*.*-*+How-*-to-Advertise-on-Usenet+biz+hated+rude+lose-*-account This already exists--but reading it is not mandatory: http://66.102.9.104/search?q=cache:SXIajvWUVHAJ:groups.google.com/support/bin/answer.py=answer=12348+Tempting-though-it-is-*-*-*-*-*-*+remove-*-*-*-irrelevant+STOP+zz-zz+qq+BOTTOM+Usenet

Note: I also use the Google Groups interface and have found that anyone who simply OBSERVES what exists and EMULATES that has no problem with posting properly to Usenet. Common sense goes a long way.

You think so? Then how else do you explain that if you see a useless follow-up completely without any quoted material to put it into context, it was posted via Google Groups *every single friggin' time*? These newbies quite obviously had no chance to get it right, because Google Groups makes it so much easier to find the "post a web forum style reply" button than the "post a Usenet follow-up with useful quoting" one that many of them don't even know the latter one exists. That's what "effictively impossible" means: too complicated for Joe Sixpack to use correctly.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

. JeffM wrote:

. To clarify: It was NEVER intrinsically *impossible* to blockquote at Google Groups. (You could always cut & paste text yourself

-->You think so? Then how else do you explain

Hyperbole. (While it is *often* true, that is no longer a function of the site's coding).

Again: **no chance** == hype. Again: Folks with common sense simply find a way to emulate what exists.

You are MANY months out of date on this.

While at one time, to get auto-generated context, you had to know to click **show options** then click THAT Reply link (with, OTOH, the Reply link which was always in plain sight giving you a blank dialog box), THIS HAS BEEN FIXED FOR QUITE SOME TIME.

This doesn't mean that there aren't still folks who strip out all blockquoting and leave you in the dark, but it isn't (quite) exclusively Google Groupers who do this.

That would be Joe Dead-Between-the-Ears ...and, as stated, this is WAY out of date. (Joe Dead-Between-the-Ears would likely not trim mega-line auto-generated blockquotes either.)

Sorry to give the wrong impression about how long it took - PAR did not take that long, it was just the case that I started PARing right before leaving the office on Thursday evening, and was not due back in to see the result until today - The actual PAR time was 33mins with the 200MHz constraint.

And now for the result:

182MHz post PAR timing.

Again - this was just a bare-bones system - purely proof of concept that XST could do it! I did not use any techniques to improve the timing result, standard levels of all options, and no xplorer. It took

3% of a V5 LX50 device.

It would be interesting to see what could be seqeezed out of this design and speed grade with the right options, or maybe using PlanAhead, but I'll leave that to others.

bart schrieb:

Bart,

please look at

its full of adult avertizing!

I was about to post a comment there, but when I see that spam there... brr!

Antti

hi Antti, unfortunately, that's one of the downsides to accepting comments instantly, without approval. you post a comment, it will be up on our blog right away!

some people will spam. typepad isn't able to block all spam. we deleted that "adult" spam comment this morning, right when we saw it. please do not hesitate to add comments to our blog based on the actions of one spammer.

if we continue to have issues with spam, we will have to pre-"approve" all comments, but we aren't to that point yet! rgds, bart

--------- Bart Borosky Manager, Online Marketing Lattice Semiconductor