EDK : FSL macros defined by Xilinx are wrong

Peter Alfke wrote:

If you want to retain the 1/2, then I suggest you use T (for
transition) instead of F (for frequency), in order to avoid the
ambiguity.
A factor of 2 might actually mean something :)
Peter Alfke
Correct, but the 'C' portion of this is usually modelled,
not physical, and called "power dissipation capacitance"
so as long as the formula is stated, the 1/2 does not matter.

eg Philips skip the 1/2, and give the formula.
Their Cpd also varies slightly with Vcc, so we have
2.0pF @1.8V and 2.7pF @3.3V for 74AUP1G175.
 
Historically, anti-fuse technology was the major player in RHESE
applications but can't offer in-field reconfigurability. It might be
worthwhile to check out the very recent FLASH-based FPGAs from Actel.
Though significantly sparser than their SRAM counterparts (no built-in
special function ASIC blocks e.g. DSP MACs), if you'r willing to
compromise on this by having a reconfigurable DSP loosely coupled with
FLASH FPGA accelerator, you might be able to pull off a decent match
to what you seek. Still this means that you guys have to develop the
whole reconfigurable platform with its supporting tools; a non-trivial
task I reckon.
 
"Anne" <anneatkinson@yahoo.com> wrote in message
news:1179331157.808046.24310@y80g2000hsf.googlegroups.com...
An ultimate goal of this sub-project is to reduce the total number of
spare parts that must be flown on a mission by having spares that are
reconfigurable such that, for example, they could function as a DSP or
microprocessor or microcontroller at any given time (just one specific
application at any given time).

Hi Anne,
Here's a thought. Imagine you make a bunch of identical thingies which can
be either a dsp, a uP, whatever. Cool, you've reduced the parts inventory.
You set off on your mission to Mars, and one of these things go wrong.
However, it turns out this is not a random failure, but a systemic failure
due to a design fault. (Perhaps the sub-contract designer mixed up imperial
and metric units?!) This means, because all your replacements are identical,
they'll all have the same fault. Kinda like the reason that some people
think GM crops are bad, because a single disease can wipe out an entire
harvest of a monoculture plant.
Maybe there's an argument to have a couple (or maybe more) different designs
of replacement. It's a long trip to Fry's from the red planet!
Cheers, Syms.
 
Hi Anne,

Anne wrote:
I am currently working on a NASA program focused on the development of
Radiation-Hardened Electronics for Space Environments (RHESE). One
portion of the sub-project I am working in support of is aimed at
developing reconfigurable modular spare electronic parts for avionics
systems.
Are you aware of the Reconfigurable Scalable Computing (RSC) project
being run out of NASA Langley?

A few web references below, but feel free to contact me directly if
you'd like more info.

http://linuxdevices.com/news/NS9415221766.html

http://www.klabs.org/mapld05/presento/130_hodson_p.ppt
http://www.klabs.org/mapld05/presento/125_somervill_p.ppt
http://www.klabs.org/mapld05/presento/1001_williams_p.ppt

Regards,

John
 
Martin Thompson wrote:
whyraja@gmail.com writes:

i want to impliment a 64 bit floating point matrix
multplication of matrix size 256*256, in verilog.
(snip)

For example..
How fast do you want to do it?
I believe it can be done as a systolic array. I have worked on
other systolic array designs, but not this one.

Are you going to use internal or external memory to store your
matrices? (Are there devices with 12MBit of internal BRAM...?)
The OP didn't say how fast it needed to be done, which is an
important parameter. That mostly tells you how many operations
you need to do at once, which then tells how much hardware you
need. It may be that it needs more than one FPGA, which would
make more memory available.

Systolic arrays tend to use both internal and external memory,
some values flowing through the pipeline, some stored internally
in each processor node.

-- glen
 
Excellent points, Symon -- things like that sure have happened in the
past! There is also some focus on "dissimilar spares" in attempts to
mitigate what you describe.
Thank you for the insight!
Anne

On May 16, 4:57 pm, "Symon" <symon_bre...@hotmail.com> wrote:
"Anne" <anneatkin...@yahoo.com> wrote in message

news:1179331157.808046.24310@y80g2000hsf.googlegroups.com...

An ultimate goal of this sub-project is to reduce the total number of
spare parts that must be flown on a mission by having spares that are
reconfigurable such that, for example, they could function as a DSP or
microprocessor or microcontroller at any given time (just one specific
application at any given time).

Hi Anne,
Here's a thought. Imagine you make a bunch of identical thingies which can
be either a dsp, a uP, whatever. Cool, you've reduced the parts inventory.
You set off on your mission to Mars, and one of these things go wrong.
However, it turns out this is not a random failure, but a systemic failure
due to a design fault. (Perhaps the sub-contract designer mixed up imperial
and metric units?!) This means, because all your replacements are identical,
they'll all have the same fault. Kinda like the reason that some people
think GM crops are bad, because a single disease can wipe out an entire
harvest of a monoculture plant.
Maybe there's an argument to have a couple (or maybe more) different designs
of replacement. It's a long trip to Fry's from the red planet!
Cheers, Syms.
 
scada wrote:

I have Visio 2003, a search for gates bought it all up.


"Richard Henry" <pomerado@hotmail.com> wrote in message
news:1179436266.635156.169680@n59g2000hsh.googlegroups.com...

Does anyone know of a location from which to download simple logic
symbol shapes for Visio (and gate, or gate, etc)?




Bill Gates??
 
In news:1179331157.808046.24310@y80g2000hsf.googlegroups.com
timestamped 16 May 2007 08:59:17 -0700, Anne L. Atkinson posted:
"I am currently working on a NASA program focused on the development
of
Radiation-Hardened Electronics for Space Environments (RHESE). One
portion of the sub-project I am working in support of is aimed at
developing reconfigurable modular spare electronic parts for avionics
systems.

An ultimate goal of this sub-project is to reduce the total number of
spare parts that must be flown on a mission by having spares that are
reconfigurable such that, for example, they could function as a DSP or
microprocessor or microcontroller at any given time (just one specific
application at any given time)."


When I had originally read the second paragraph it had not seemed to me
that the type of spare items (e.g. "a DSP or
microprocessor or microcontroller") are to be so restricted as to be
only MicroBlazes; PicoBlazes; and some as yet undecided DSPs listed
further down in
news:1179331157.808046.24310@y80g2000hsf.googlegroups.com for Path
2. Though you mentioned spare copies of what are already planned for a
spacecraft, I suspect that this could be a narrower view than
necessary: e.g. gyroscopes or other parts can eventually become noisy
(or even completely useless) so some leftover unused logic could
conceivably be used to apply extra filtering (or extra computational
power for a more advanced control law) instead of simply providing a
replacement of part of the originally designed electronics. Of course,
we could spend forever thinking of every possible alternative way to
exploit something.

If you plan to reduce the number of spare devices on board by using
reconfigurable spare devices, you run the risk that you will need more
physical spares than you actually launched. Of course, this could
also happen without reconfigurable spare devices.


" (And one obvious question here is --
exactly what specific functionality is desired from the
microprocessor, microcontroller, or DSP that this part will implement?
- that does not seem to be entirely clear yet on this project - when I
pose those questions, I don't get answers. That's a bit frustrating
(to me anyhow), but for now, that is just how it is!)

[..]

Also, since "path 1" will require a lot more time and effort for in-
house design / development to implement the desired functionalities,
I am thinking that "path 2" may provide for a good initial
demonstration of capabilities (in general, since at current there do
not seem to be specifics with regard to the desired capabilities!),
with the hopes that "path 1" can be pursued over a longer period of
time with a greater degree of focus on the _specific_ capabilities and
characteristics that are ultimately decided upon.

[..]

I wish I could provide more specifics on exactly what specific
functionality is desired from the microprocessor, microcontroller, or
DSP that this part will implement... As I said, that is currently a
frustration of mine, and I know that makes it tough to provide insight
on the best development path. I am hoping that as the process of
specifying appropriate development platforms progresses, the
performance and other characteristics of the platforms specified will
help the folks here work towards more clarity on the specifics of what
they need."

I empathize with discontentment arising from questions being
unanswered. E.g. on April 13th, 2007 and May 15th, 2007 I asked the
main tutor for my Ph.D. would we be able to obtain papers such as
T. Vladimirova and D. Zheng, "Reconfigurable System-on-a-Chip Based
Computing Platform for Small Satellites", "Proceedings of the 1st
Annual ESA Workshop on Spacecraft Data Systems and Software", SDSS
2005, ESTEC, Noordwijk, The Netherlands, 17-20 October 2005 and
others listed on
WWW.EE.Surrey.ac.UK/SSC/G11/P5/
and
T. Vladimirova, P. Davies, M. Sweeting, "Reconfigurable Computing
for Micro-Satellites", DASIA 2006 listed on
WWW.Eurospace.org/dasia2006_programme_update_31_07_06.pdf
and I am unfortunately still waiting.


"I've been tasked with evaluation of potential development platforms
for these modular spares. This is a bit "out of the box" for me -- my
background is primarily in system software development -- I'm not a
hardware designer -- but, this has been very interesting and I'm
trying to learn and do my best at it."

I wish success for the project. The longest of my degrees so far was for
computer science. I am not exactly perfect myself, see e.g.
news:f2hoij$v4e$1@newsserver.cilea.it



"After spending some time trying to spin-up on reconfigurable
hardware / systems through books (a colleague lent me a copy of
The_Design_Warrior's_Guide_to_FPGAs_ by Clive "Max" Maxfield which has
been a very good tutorial / reference - I recommend it!)"

I am not familiar with Clive Maxfield.



" papers, and
google searches, my current thoughts are towards a "dual path"
development plan:

Path 1: Use a cutting edge platform in the genre of what Clive "Max"
Maxfield refers to as a "Field Programmable Node Array (FPNA)" in the
above mentioned book in an attempt to get the most flexible end
product from the standpoint of reconfigurability, power consumption,
board/device size,"

I am unfamiliar with the term ""Field Programmable Node Array (FPNA)"".

" and a novel approach to provision of radiation
tolerance."

If it would not be illegal copyright infringement to do so, could you
please reveal what this approach is?


" Current plan here is to use a platform and associated
development toolset provided by a small start-up company -- so
relatively high risk, but good potential benefits if it all comes
together well."

Do you have a particular "small start-up company" in mind, or do you
simply associate new technology as outside the realm of established
companies?

"Path 2: [..] which uses:
1) MicroBlaze soft core to implement microprocessor functionality
2) PicoBlaze soft core to implement microcontroller functionality
3) ??? some soft core provided through the above development tools
(or from some other source?) to implement DSP functionality"

What if someone wanted to use a different instruction set processor?
E.g. someone in NASA uses a Silicon Laude 8051 clone,
WWW.SiliconLaude.com
(Robert F. Jarnot, "Re: 8051 IP core with JTAG debugger for FPGA?",
comp.arch.fpga, Thu, 23 Feb 2006 13:33:10 -0800, Message-ID:
<dtl9mo$b6b$1@nntp1.jpl.nasa.gov> ), and someone else in NASA uses a
completely different instruction set.


"Path 2: Target a Xilinx FPGA-based platform of some type - from what
looking through information / references on the Xilinx web site, I'm
thinking of possibly using a combination of Xilinx's ISE and EDK
development tools to develop a reconfigurable platform [..]"

Xilinx is not the only manufacturer of FPGAs. In what way is using
extremely buggy software (whether from Xilinx or another supplier of
buggy software for FPGAs) not risky?

"[..]

So I have some questions / concerns, on which I hope some folks with
more knowledge of this arena can help give me insight:

* Am I going down reasonable paths to pursue the end goals here? I
have a little wellspring of doubt about all my thoughts since hardware
specs / design is not something in which I have experience (plus it's
just kinda my nature to doubt and worry!!! ;) :) ). I'd appreciate
any insight, positive or negative, on this point."

It is good to be skeptical.

"* I was going to try to contact a Xilinx field engineer to ask about
the viability of a Xilinx-FPGA based platform, and if that is viable,
to get recommendations on appropriate platforms / development boards /
development tools / IP cores to work towards the desired end-goal
functionality;"

Perhaps you are not skeptical. Which company do you suspect an
employee of Xilinx would recommend?

" however, from looking through the Xilinx web site
(which provides a lot of excellent reference information -- it's
almost overwhelming to a newby in this arena like me!) "

Be wary of the information concerning GEO on Slide 27 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
[VII Testing - SEFI2
* MTBF calculations for POR+JCFG SEFI at different orbits
.. POR SEFI is worse case ; JTAG is better than SelectMAP
Orbit Altitude Inclination Upset Rate MTBF
(km) (degrees) (SEU/device/day)
(Years/Event)
LEO 400 51.6 2.33E-06 2,185
LEO 800 22.0 9.87E-06 277
Polar 833 98.7 5.44E-06 503
Const. 1,200 65.0 2.74E-05 100
GEO 36,000 0.0 2.00E-06 1,369]
as GEO is actually not a relatively safe location for electronics
(especially when it is not part of the Earth's magnetosphere during
solar maximum!).

Slide 36 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
contains something which is plainly untrue:
"TMR Overview
* Triplication Technique is called TMR (Triple
Module Redundancy)
.. Logic is triplicated INSIDE the FPGA
* Don.t have to do this by hand anymore!!! TMRTool
.. Single Point Failures are eliminated
.. TMR analysis includes:
* Throughput Logic
* Feedback Logic w/ voters
* Output voting"
as confessed on Slide 36:
"[..]
* We can.t PREVENT SEUs and SETs...
* We can only MITIGATE their effects...
[..]"

I.e. a single point failure is not eliminated: where the winning
decision of a voting system is determined is a single point of
failure. One approach (which is still not perfect) (which is not
mentioned on that slide which is concerned with TMR inside one FPGA)
is to use three FPGAs as voters and for the component which is to
decide the winning value of the vote, to use a component in which
greater confidence in its resistance to radiation is justified (e.g. a
one time field programmable gate array), e.g. a checker of a safer
technology is mentioned in e.g. Cheung Ed;
William I. Clement; and Ray Bietry, "Reconfigurable Avionics for
Hubble Servicing Missions", MAPLD 2003,
Klabs.org/richcontent/MAPLDCon03/papers/p/p11_cheung_p.pdf
and seems to be shown on Slide 57 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
(unfortunately the Cheung; Clement; and Bietry paper and another MAPLD
paper did not contain anything positive about Single Event Transients
(for which one might deliberately use clocks out of phase for voters
as in the spatial voting scheme reviewed in Blum; Delgado-Frias;
"Schemes for Eliminating
Transient-Width Clock Overhead From SET-Tolerant Memory-Based
Systems", "IEEE TRANSACTIONS ON NUCLEAR SCIENCE", VOL. 53, NO. 3, JUNE
2006) and I received no response to my complaints (but a strict subset
of the email addresses I tried bounced)).

Prof. William H. Sanders boasted during a lecture (this webpage does
not go into enough detail to show the boast:
WWW.IET.UniPi.It/dottinformazione/Formazione/OffForm2006/Sanders/Validating.html
) that many years ago he had convinced people of NASA's that some
reliability problem could be satisfactorily tackled. In his solution,
voters or similar checkers were used but at least in the lecture he
had not addressed the issue of a failure in a checker so I raised this
issue. He has responded in the lecture that of course the issue of who
checks the checker is an unsolvable problem and so he would have much
simpler (and hence hopefully less prone to obscure, complicated
errors) logic as a checker than the logic it checks.

WWW.Xilinx.com/bvdocs/appnotes/xapp181.pdf
contains many more techniques, none of which is perfect as perfection
is not possible if any arbitrary fault is possible.

Always be sceptical of the context in which something is claimed,
e.g. from Slide 4 of both
WWW.Xilinx.com/products/milaero/MilAero.pdf
and
WWW.Xilinx.com/esp/mil_aero/collateral/presentations/radiation_effects.pdf
:"Rad-Tolerant vs Military
* Rad-Tolerant devices = Military Devices +
.. Epitaxial Substrate Wafer (2 microns)
* Used for latch-up immunity
[..]"
but from other slides such as Slide 65 of
WWW.Xilinx.com/products/milaero/MilAero.pdf
:"[..]
Solution: Use of epitaxial substrate => Virtex II is immune to SEL
upto LET > 160 Mev.cm2/mg"

I was surprised at home much attention is given to neutrons on
WWW.Xilinx.com/esp/mil_aero/collateral/presentations/radiation_effects.pdf
but by Slide 80 I remembered that that file is also relevant to aircraft.


In news:1179331157.808046.24310@y80g2000hsf.googlegroups.com
timestamped 16 May 2007 08:59:17 -0700, Anne L. Atkinson posted:

"[..] Where would I
find good points of contact to ask questions and get advice on
potential platforms / development tools, etc. to begin determining the
best selections for a "path 2" platform?

[..]"

John Williams has already advised you in
news:464B9365.9040105@itee.uq.edu.au
of NASA employee Richard B. Katz's website for MAPLD. I am sure that
Richard B. Katz would love to help you. However, I am not convinced
that everything which is accepted for MAPLD is of high quality.

Dr. Tanya Vladimirova is a pleasant person to speak to and might also
be willing to help you.

I may be willing to help you, as part of my Ph.D., and quite possibly I
will not need money from you as I already receive funding from a scholarship.
However, I might not know what you need an assistant to know.

In news:1179342111.272834.71290@u30g2000hsc.googlegroups.com
timestamped 16 May 2007 12:01:51 -0700, Manny <mloulah@hotmail.com>
posted:
"Historically, anti-fuse technology was the major player in RHESE
applications but can't offer in-field reconfigurability."

Perhaps suitability for space should be more important than
reconfigurability. Various factors affecting a reconfigurable FPGA
such as temperature can not be expected to be the same on the
engineering model as on the board on orbit so plenty of problems could
result from delicate timing violations.

" It might be
worthwhile to check out the very recent FLASH-based FPGAs from Actel."

Someone in the European Space Agency advised against Flash (much as
one would be wary of EEPROM) but I do not know of what that person
would recommend to use.

"Though significantly sparser than their SRAM counterparts (no built-in
special function ASIC blocks e.g. DSP MACs), if you'r willing to
compromise on this by having a reconfigurable DSP loosely coupled with
FLASH FPGA accelerator, you might be able to pull off a decent match
to what you seek. Still this means that you guys have to develop the
whole reconfigurable platform with its supporting tools; a non-trivial
task I reckon."

Maybe.

Regards,
Nicholas Paul Collin Gloster
 
"Sylvain Munaut" <tnt-at-246tNt-dot-com@youknowwhattodo.com> wrote in
message news:464E266F.2070308@youknowwhattodo.com...
Weng Tianxiang wrote:

I want to know which one is tabulator (tab).

ht
or vt
 
On Sat, 19 May 2007 12:06:25 +0100,
<symon_brewer@hotmail.com> wrote:

I want to know which one is tabulator (tab).

ht

or vt
I know what VT did on an ASR33 Teletype, but
I'm not at all sure what it's supposed to do
these days ...

Tabs of any kind are extremely bad news anyway,
because their appearance is so strongly dependent
on the editor or viewer that you use to do the
rendering. I hate 'em. Compute how many spaces
you need and insert the spaces explicitly.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On May 19, 7:09 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Sat, 19 May 2007 12:06:25 +0100,

symon_bre...@hotmail.com> wrote:
I want to know which one is tabulator (tab).

ht
or vt

I know what VT did on an ASR33 Teletype, but
I'm not at all sure what it's supposed to do
these days ...

Tabs of any kind are extremely bad news anyway,
because their appearance is so strongly dependent
on the editor or viewer that you use to do the
rendering. I hate 'em. Compute how many spaces
you need and insert the spaces explicitly.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Hi Jonathan,
This time I don't agree with your opinion.

What I do is to print out all related waveforms I am interested in and
using tab is to make me easier to manually check if the waveforms are
right so that a software can be used later to check the waveforms
without 1 clock after another to manually check waveforms.

'ht' works for tab in VHDL.

Salvain,
Thank you.

Weng
 
In news:464B9365.9040105@itee.uq.edu.au timestamped Thu, 17 May 2007
09:27:33 +1000, John Williams <jwilliams@itee.uq.edu.au> posted:
"[..]

Are you aware of the Reconfigurable Scalable Computing (RSC) project
being run out of NASA Langley?

A few web references below, but feel free to contact me directly if
you'd like more info.

http://linuxdevices.com/news/NS9415221766.html

http://www.klabs.org/mapld05/presento/130_hodson_p.ppt
http://www.klabs.org/mapld05/presento/125_somervill_p.ppt
http://www.klabs.org/mapld05/presento/1001_williams_p.ppt

Regards,

John"


Dear Dr. Williams,

I note that the term "Bus" appears twice on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#299,9,Reconfigurable Processing Module
in contrast to the term "Scalable Network" on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#268,4,Scalable Architecture

Is the cache mentioned on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#308,10,RPM Features
suitable for realtime use?

"Xilinx logic is triplicated" on
WWW.Klabs.org/mapld05/presento/130 hodson p.ppt#308,10,RPM Features
is not detailed enough to show what risks your form of triplication is susceptible to and resilient to. On
WWW.Klabs.org/mapld05/presento/125 somervill p.ppt#281,10,Embedded Processing
it is written:
"Design mitigated with XTMR tool (or manually)".
What drives your choice for the XTMR tool or manual error detection and correction? However, I note from
WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#266,11,MicroBlaze, Linux and RSC
that your reconfigurable systems for NASA are not intended for spacecraft survivability, so protection against errors might not be very important for you.

On
WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#285,16,MicroBlaze Multiprocessing
it is claimed
"We can put about 8 CPUs in an FPGA"
so what is the 33% utilization "of FIFO16/RAM16s" on
WWW.Klabs.org/mapld05/presento/1001_williams_p.ppt#260,9,MicroBlaze
for?

Thanks,
Colin Paul Gloster
 
On 19 May 2007 18:58:35 -0700, Weng Tianxiang wrote:

This time I don't agree with your opinion.

What I do is to print out all related waveforms I am interested in and
using tab is to make me easier to manually check if the waveforms are
right so that a software can be used later to check the waveforms
without 1 clock after another to manually check waveforms.
Ah - you are using tabs to create a tab-separated file for
Excel or some similar software? If so, then I'm sorry - yes -
that's OK.

I still think tabs are a crazy way to create human-readable
layouts, because different editors and terminals may handle
tabs in different ways. It can get *very* ugly.

ht works for tab in VHDL.
Indeed.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:gvu253htpodsk3cs4vj186nqqrimoe9ni7@4ax.com...
On 19 May 2007 18:58:35 -0700, Weng Tianxiang wrote:

What I do is to print out all related waveforms I am interested in and
using tab is to make me easier to manually check if the waveforms are
right so that a software can be used later to check the waveforms
without 1 clock after another to manually check waveforms.

Ah - you are using tabs to create a tab-separated file for
Excel or some similar software? If so, then I'm sorry - yes -
that's OK.

....but I'd recommend CSV as a better solution for that application.
HTH, Syms.
 
Symon wrote:
(snip on TAB character)

...but I'd recommend CSV as a better solution for that application.
CSV is probably best as long as the fields can't contain
a comma. If they do, then some will quote each string, unless
the strings can contain quotes. If the do, then...

-- glen
 
Pablo Bleyer Kocik wrote:
Dear group:

PacoBlaze 2.2 has been released. This version solves some bugs that
were still lurking in the stack and interrupt manipulation. The cores
have also received more testing, and more debug information has been
added to simulations enabled with the HAS_DEBUG macro. Instructions
also have now a one-hot encoding format that is used when
USE_ONEHOT_ENCODING is defined. Unfortunately, the compatibility with
Icarus Verilog is broken but I am still working on it.

The KCAsm assembler has been tweaked a bit to accept constructs in
the form of the original KCPSM assembler, so that most PSM files
should be accepted with little or no modification.

The PacoBlaze web site is at http://bleyer.org/pacoblaze, where you
can find more information and links to the source distribution.
Hi Pablo,
Can you add a simple table of Options/Resource, along the lines of
the one here ?

http://www.latticesemi.com/Mico8

-jg
 
On May 29, 4:40 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
Pablo Bleyer Kocik wrote:
Dear group:

PacoBlaze 2.2 has been released. This version solves some bugs that
were still lurking in the stack and interrupt manipulation. The cores
have also received more testing, and more debug information has been
added to simulations enabled with the HAS_DEBUG macro. Instructions
also have now a one-hot encoding format that is used when
USE_ONEHOT_ENCODING is defined. Unfortunately, the compatibility with
Icarus Verilog is broken but I am still working on it.

The KCAsm assembler has been tweaked a bit to accept constructs in
the form of the original KCPSM assembler, so that most PSM files
should be accepted with little or no modification.

The PacoBlaze web site is athttp://bleyer.org/pacoblaze, where you
can find more information and links to the source distribution.

Hi Pablo,
Can you add a simple table of Options/Resource, along the lines of
the one here ?

http://www.latticesemi.com/Mico8

-jg
Jim, the link is broken. What kind of table are you referring to?
PacoBlaze has been written from scratch following Xilinx's
documentation of their PicoBlaze processor, so any resource
configuration (registers, instructions, scratchpad memory) applies to
PacoBlaze. The only exception are my own extensions for PacoBlaze3m
(16-bit ALU with multiplier).

Regards.
 
Pablo Bleyer Kocik wrote:
http://www.latticesemi.com/Mico8
Jim, the link is broken.
http://www.latticesemi.com/mico8

is the correct link.

What kind of table are you referring to?
Ressource usage (i.e. number of slices, registers and such) depending on
what FPGA is used and what features are implemented.

cu,
Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...
 
Pablo Bleyer Kocik wrote:
http://www.latticesemi.com/Mico8

-jg


Jim, the link is broken.
Oops, try

http://www.latticesemi.com/mico8

On the page that jumps to, they tabulate

Device LUTs Registers SLICEs f MAX (MHz)

I thought a similar simple summary would be good for your core, too?


What kind of table are you referring to?
PacoBlaze has been written from scratch following Xilinx's
documentation of their PicoBlaze processor, so any resource
configuration (registers, instructions, scratchpad memory) applies to
PacoBlaze. The only exception are my own extensions for PacoBlaze3m
(16-bit ALU with multiplier).

Regards.
 
On May 29, 6:49 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
Pablo Bleyer Kocik wrote:

http://www.latticesemi.com/Mico8

-jg

Jim, the link is broken.

Oops, try

http://www.latticesemi.com/mico8

On the page that jumps to, they tabulate

Device LUTs Registers SLICEs f MAX (MHz)

I thought a similar simple summary would be good for your core, too?
LOL. It never occurred to me to change the uppercase M to a
lowercase. ;-)

The implementation depends very much on the device and post-route
tweaking, but for Xilinx devices I get ~200 slices and speeds around
100MHz for PB3.

Regards.
 

Welcome to EDABoard.com

Sponsor

Back
Top