Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 155350

Article: 155350
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Mon, 24 Jun 2013 06:28:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, June 24, 2013 8:30:46 AM UTC-4, Tom Gardner wrote:

> Consider what happens if interrupt occurs at inopportune moment in the above sequence, and the other thread runs. You can get double or missed updates.

I think you're missing the point that in my processor the threads run concurrently, not sequentially.

Article: 155351
Subject: Re: FPGA Exchange
From: hamilton <hamilton@nothere.com>
Date: Mon, 24 Jun 2013 07:31:31 -0600
Links: << >>  << T >>  << A >>
On 6/24/2013 5:20 AM, Uwe Bonnes wrote:
> Guy Eschemann <Guy.Eschemann@gmail.com> wrote:
>> I'd like to introduce a new FPGA discussion forum. It's called
>> FPGA Exchange, and you can check it out at: http://fpga-exchange.com
>
>> Feel free to jump in, create new topics, or answer existing ones.
>
> Any reason for trying to split up the community?
>
Time will tell if fpga-exchange will offer new or better discussions.

There is always room for a new kid, lets see if it lasts.

hamilton


Article: 155352
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 24 Jun 2013 14:47:28 +0100
Links: << >>  << T >>  << A >>
Eric Wallin wrote:
> On Monday, June 24, 2013 8:30:46 AM UTC-4, Tom Gardner wrote:
>
>> Consider what happens if interrupt occurs at inopportune moment in the above sequence, and the other thread runs. You can get double or missed updates.
>
> I think you're missing the point that in my processor the threads run concurrently, not sequentially.

Nope. That usually exacerbates problems, plus having 8-port memory (one for each thread) is not cheap!

Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made?


Article: 155353
Subject: Re: VHDL syntheses timestamp
From: "padudle" <93037@embeddedrelated>
Date: Mon, 24 Jun 2013 09:02:19 -0500
Links: << >>  << T >>  << A >>
This is a good thread.

In out system, the application software would check a version number
register at boot time to make sure it was running with the right FPGA
design.  The problem with my manually updated version register is that I
always forgot to update it until after the FPGA build and test work was
done.  To update the version number I had to re-run the FPGA build and, of
course, the testing.

Our FPGA had a PCIe interface so it must configure from an on-board flash
in order to boot in time for PCIe enumeration cycles.  The on-board
configuration flash is readable and writeable across the PCIe bus by the
Linux host. Eventually, I noticed that the Xilinx configuration bit file
header contains a date and time that is automatically incremented at build
time.  

I tried to get the software guys to just read the bit file header and parse
the date and time out of there.  They could have just used those fields as
a unique identifier.  In the end, I could never convince them to do that.

I have actually, sent suggestions to Xilinx on this subject but I haven't
heard of any enhancements to support an automatically updated version or
date/time register in the code.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155354
Subject: Re: VHDL syntheses timestamp
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 24 Jun 2013 14:41:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
padudle <93037@embeddedrelated> wrote:
 
> In out system, the application software would check a version number
> register at boot time to make sure it was running with the right FPGA
> design.  The problem with my manually updated version register is that I
> always forgot to update it until after the FPGA build and test work was
> done.  To update the version number I had to re-run the FPGA build and, of
> course, the testing.
 
If you use a version control systems, such as CVS, SVN, 
(and I believe also GIT) there is a way to have it automatically 
update a field in the file as it is checked in with the version
number. You should be able to use that to make a hardware readable
register with the version number in it.

-- glen

Article: 155355
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Mon, 24 Jun 2013 08:57:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote:

> Please explain why your processor does not need test and set or compare a=
nd exchange operations. What theoretical advance have you made?

I'm not exactly sure why we're having this generalized, theoretical discuss=
ion when a simple reading the design document I've provided would probably =
answer your questions.  If it doesn't then perhaps you could tell me what I=
 left out, and I might include that info in the next rev.  Not trying to be=
 gruff or anything, I'd very much like the document (and processor) to be o=
n as solid a footing as possible.

Article: 155356
Subject: Re: FPGA Exchange
From: "RCIngham" <2161@embeddedrelated>
Date: Mon, 24 Jun 2013 11:06:45 -0500
Links: << >>  << T >>  << A >>
I get a message "Unfortunately, your browser is too old to work on this
Discourse forum. Please upgrade your browser."
The IT Department here determine what browser I use, so I won't be
contributing.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155357
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 24 Jun 2013 17:13:39 +0100
Links: << >>  << T >>  << A >>
Eric Wallin wrote:
> On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote:
>
>> Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made?
>
> I'm not exactly sure why we're having this generalized, theoretical discussion when a simple reading the design document I've provided would probably answer your questions.

Please point me to the section which discusses the primitive operations/attributes/properties that you have provided to enable inter-thread communication.


> If it doesn't then perhaps you could tell me what I left out, and I might include that info in the next rev.

Sorry, I don't have time to poorly recapitulate subjects that have been know about and solved for decades.


>  Not trying to be gruff or anything, I'd very much like the document (and processor) to be on as solid a footing as possible.

Ditto, and I don't have time to find the flaws in your arguments.

If you want people to use your processor, it might be wise to give them the information they need to have confidence in its design.



Article: 155358
Subject: Re: New soft processor core paper publisher?
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Jun 2013 12:35:02 -0400
Links: << >>  << T >>  << A >>
On 6/24/2013 11:57 AM, Eric Wallin wrote:
> On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote:
>
>> Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made?
>
> I'm not exactly sure why we're having this generalized, theoretical discussion when a simple reading the design document I've provided would probably answer your questions.  If it doesn't then perhaps you could tell me what I left out, and I might include that info in the next rev.  Not trying to be gruff or anything, I'd very much like the document (and processor) to be on as solid a footing as possible.

Eric, I think you have explained properly how your design will deal with 
synchronization.  I'm not sure what Tom is going on about.  Clearly he 
doesn't understand your design.

If it is of any help, Eric's design is more like 8 cores running in 
parallel, time sharing memory and in fact, the same processor hardware 
on a machine cycle basis (so no 8 ported memory required).  If an 
interrupt occurs it doesn't cause one of the other 7 tasks to run, they 
are already running, it simply invokes the interrupt handler.  I believe 
Eric is not envisioning multiple tasks on a single processor.

As others have pointed out, test and set instructions are not required 
to support concurrency and communications.  They are certainly nice to 
have, but are not essential.  In your case they would be superfluous.

-- 

Rick

Article: 155359
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 24 Jun 2013 17:56:05 +0100
Links: << >>  << T >>  << A >>
rickman wrote:
> On 6/24/2013 11:57 AM, Eric Wallin wrote:
>> On Monday, June 24, 2013 9:47:28 AM UTC-4, Tom Gardner wrote:
>>
>>> Please explain why your processor does not need test and set or compare and exchange operations. What theoretical advance have you made?
>>
>> I'm not exactly sure why we're having this generalized, theoretical discussion when a simple reading the design document I've provided would probably answer your questions.  If it doesn't then
>> perhaps you could tell me what I left out, and I might include that info in the next rev.  Not trying to be gruff or anything, I'd very much like the document (and processor) to be on as solid a
>> footing as possible.
>
> Eric, I think you have explained properly how your design will deal with synchronization.  I'm not sure what Tom is going on about.  Clearly he doesn't understand your design.

Correct.

> If it is of any help, Eric's design is more like 8 cores running in parallel, time sharing memory and in fact, the same processor hardware on a machine cycle basis
>(so no 8 ported memory required).

Fair enough; sounds like it is in the same area as the propellor chip.

Is there anything to prevent multiple cores reading/writing the
same memory location in the same machine cycle? What is the
result when that happens?


> If an interrupt occurs it doesn't cause one of the other 7 tasks to run, they are already running, it simply invokes the interrupt handler.  I believe Eric is not envisioning multiple tasks on a
> single processor.

Such presumptions would be useful to have in the white paper.


> As others have pointed out, test and set instructions are not required to support concurrency and communications.  They are certainly nice to have, but are not essential.

Agreed. I'm perfectly prepared to accept alternative techniques,
e.g. disable interrupts.


> In your case they would be superfluous.

Not proven to me.

The trouble is I've seen too many hardware designs that
leave the awkward problems to software - especially first
efforts by small teams.

And too often those problems can be very difficult to solve
in software. Nowadays it is hard to find people that have
sufficient experience across the whole hardware/firmware/system
software spectrum to enable them to avoid such traps.

I don't know whether Eric is such a person, but I'm afraid
his answers have raised orange flags in my mind.

As a point of reference, I had similar misgivings when I
first heard about the Itanium's architecture in, IIRC,
1994. I suppressed them because the people involved were
undoubtedly more skilled in the area that I, and had been
working for 5 years. Much later I regrettably came to the
conclusion the orange flags were too optimistic.


Article: 155360
Subject: Re: VHDL syntheses timestamp
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Mon, 24 Jun 2013 10:15:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
I've done this with my own makefile, but next time I'd like to try this wit=
h the Synplify callback function.  (If you aren't using Synplify, this prob=
ably won't help in your case.)  Synplify lets you write TCL callback functi=
ons, for example, one that will run right before synthesis, so you could th=
eoretically write a simple 3-line TCL function that would create a date sta=
mp even if you're using the GUI.

Article: 155361
Subject: Re: VHDL syntheses timestamp
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Mon, 24 Jun 2013 19:48:49 +0200
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:
> I've done this with my own makefile, but next time I'd like to try
> this with the Synplify callback function.  (If you aren't using
> Synplify, this probably won't help in your case.)  Synplify lets you
> write TCL callback functions, for example, one that will run right
> before synthesis, so you could theoretically write a simple 3-line
> TCL function that would create a date stamp even if you're using the
> GUI.

Vivado now allows execution of pre-synthesis TCL scripts that can be
used to generate e.g. a VHDL package file containing version
numbers/time stamps.

Unfortunately, AFAIK this currently (as of Vivado 2013.2) is not usable
in this case, because Vivado will detect the source files have changed
AFTER synthesis, hence it will always complain that your synthesis
results are out-of date. This is a known bug and I was promised that
would be fixed in 2013.1, which obviously it wasn't...

So I'm sticking with my scripted flow.

Greetings,
Sean

Article: 155362
Subject: Re: New soft processor core paper publisher?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 24 Jun 2013 18:01:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

(snip)
> Is there anything to prevent multiple cores reading/writing the
> same memory location in the same machine cycle? What is the
> result when that happens?

Yes. Even if the threads don't communicate with each other, they
might share I/O devices which needs some communication.
 
(sniP)

> The trouble is I've seen too many hardware designs that
> leave the awkward problems to software - especially first
> efforts by small teams.

The 8087 was originally designed to have a virtual stack, where
on stack overflow an interrupt would trigger a software routine
to spill some stack registers to memory, and on underflow bring
them back again. But no-one tried to write the interrupt routine
until the hardware was done, and it turned out that it wasn't
possible. Not all the required state was available or settable.

They might have fixed it in the 80287, but then they had to be
compatible with the 8087. Actually, I don't know why they didn't
fix it, but it still isn't fixed. 

-- glen

Article: 155363
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 24 Jun 2013 19:45:29 +0100
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>
> (snip)
>> Is there anything to prevent multiple cores reading/writing the
>> same memory location in the same machine cycle? What is the
>> result when that happens?
>
> Yes. Even if the threads don't communicate with each other, they
> might share I/O devices which needs some communication.
>
> (sniP)
>
>> The trouble is I've seen too many hardware designs that
>> leave the awkward problems to software - especially first
>> efforts by small teams.
>
> The 8087 was originally designed to have a virtual stack, where
> on stack overflow an interrupt would trigger a software routine
> to spill some stack registers to memory, and on underflow bring
> them back again. But no-one tried to write the interrupt routine
> until the hardware was done, and it turned out that it wasn't
> possible. Not all the required state was available or settable.

Oh, inaccessible state is a problem that has been repeated
many times in many companies! Often to be found near to
virtual memory tables, exceptions, interrupts, and
debuggers - making Heisenbugs the norm not the exception :(


> They might have fixed it in the 80287, but then they had to be
> compatible with the 8087. Actually, I don't know why they didn't
> fix it, but it still isn't fixed.

I strongly suspect compatibility is the (fully justifiable)
reason; it is the reason for all sorts of hardware and
software cruft.


Article: 155364
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Mon, 24 Jun 2013 12:25:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, June 24, 2013 12:07:23 AM UTC-4, rickman wrote:

> I'm glad you can take (hopefully) constructive criticism.  I was=20
> concerned when I wrote the above that it might be a bit too blunt.

I apologize to everyone here, I kind of barged in and have behaved somewhat=
 brashly.

> ... part of the utility=20
> of a design is the ease of programming efficiently.  I haven't looked at=
=20
> yours yet, but just picturing the four stacks makes it seem pretty=20
> simple... so far. :^)=20

Writing a conventional stack machine in an HDL isn't too daunting, but prog=
ramming it afterward, for me anyway, was just too much.

> I have to say I'm not crazy about the large instruction word.  That is=20
> one of the appealing things about MISC to me.  I work in very small=20
> FPGAs and 16 bit instructions are better avoided if possible, but that=20
> may be a red herring.  What matters is how many bytes a given program=20
> uses, not how many bits are in an instruction.

Yes.  Opcode space obviously expands exponentially with bit count, so one c=
an get a lot more with a small size increase.  I think a 32 bit opcode is p=
ushing it for a small FPGA implementation, but a 16 bit opcode gives one a =
couple of small operand indices, and some reasonably sized immediate instru=
ctions (data, conditional jumps, shifts, add) that I find I'm using quite a=
 bit during the testing and verification phase.  Data plus operation in a s=
ingle opcode is hard to beat for efficiency but it has to earn it's keep in=
 the expanded opcode space.  With the operand indices you get a free copy/m=
ove with most single operand operations which is another efficiency.

> I am supposed to present to the SVFIG and I think your design would be a=
=20
> very interesting part of the presentation unless you think you would=20
> rather present yourself.  I'm sure they would like to hear about it and=
=20
> they likely would be interested in your opinions on MISC.  I know I am.

I'm on the other coast so I most likely can't attend, but I would be most h=
onored if you were to present it to SVFIG.

Article: 155365
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Mon, 24 Jun 2013 12:47:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, June 24, 2013 12:56:05 PM UTC-4, Tom Gardner wrote:

> The trouble is I've seen too many hardware designs that
> leave the awkward problems to software - especially first
> efforts by small teams.

I know what you mean.  Maybe I'm too picky, or perhaps too rigid to conform=
 to other's coding styles, but 90% of the HDL code I've encountered both vo=
cationally and avocationally  has been quite poor.  I tend to rewrite every=
thing, including my slightly older code if I'm using it again, because my s=
tyle keeps evolving, and it never hurts to take another look at things or a=
t least give them some more polish.

> And too often those problems can be very difficult to solve
> in software. Nowadays it is hard to find people that have
> sufficient experience across the whole hardware/firmware/system
> software spectrum to enable them to avoid such traps.
>
> I don't know whether Eric is such a person, but I'm afraid
> his answers have raised orange flags in my mind.

Processors aren't my main thing, but I do have need of them in my main thin=
g so I've been quite interested in them for ~15 years now.  My EE graduate =
adviser was a professor of computer engineering and I took a couple of his =
courses.  I own and have read the two Hennesey & Patterson (sp?) texts, tho=
ugh I must admit my eyes glazed over when TLBs and pipeline hazards were be=
ing discussed.

Discovering stack machines was a transforming experience for me, showing th=
at it was possible to have much simpler and tractable HW underlying it all.=
  But it's hard to beat indexed registers.  This hybrid is something of a m=
iddle ground, and so far I'm not finding it too revolting to program by han=
d - then again it might be something only a mother can love.

Article: 155366
Subject: Re: New soft processor core paper publisher?
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Mon, 24 Jun 2013 21:02:32 +0100
Links: << >>  << T >>  << A >>
Eric Wallin wrote:
> On Monday, June 24, 2013 12:56:05 PM UTC-4, Tom Gardner wrote:
>
>> The trouble is I've seen too many hardware designs that
>> leave the awkward problems to software - especially first
>> efforts by small teams.
>
> I know what you mean.  Maybe I'm too picky, or perhaps too rigid to conform to other's coding styles, but 90% of the HDL code I've encountered both vocationally and avocationally  has been quite poor.  I tend to rewrite everything, including my slightly older code if I'm using it again, because my style keeps evolving, and it never hurts to take another look at things or at least give them some more polish.
>
>> And too often those problems can be very difficult to solve
>> in software. Nowadays it is hard to find people that have
>> sufficient experience across the whole hardware/firmware/system
>> software spectrum to enable them to avoid such traps.
>>
>> I don't know whether Eric is such a person, but I'm afraid
>> his answers have raised orange flags in my mind.
>
> Processors aren't my main thing, but I do have need of them in my main thing so I've been quite interested in them for ~15 years now.  My EE graduate adviser was a professor of computer engineering and I took a couple of his courses.  I own and have read the two Hennesey & Patterson (sp?) texts, though I must admit my eyes glazed over when TLBs and pipeline hazards were being discussed.
>
> Discovering stack machines was a transforming experience for me, showing that it was possible to have much simpler and tractable HW underlying it all.  But it's hard to beat indexed registers.  This hybrid is something of a middle ground, and so far I'm not finding it too revolting to program by hand - then again it might be something only a mother can love.

Doing something "just because I want to" is an _excellent_
reason. For me probably the next such project will be to
make a cheapskate 1GS/s oscilloscope & TDR. But there's a
heck of a learning curve w.r.t. FPGA clocking, i/o
structures, floorplanning and dev kits nowadays!

Whenever I've come across people that say "if you have
problem X then my product will solve it provided Y applies",
I give them more credence if they also say "but my product
doesn't do Z, you have to do that some other way".
I'm sure you've had similar experiences.

Article: 155367
Subject: Re: Modelsim ought to be cheaper
From: Sanjay Parekh <parekhsanjayh@gmail.com>
Date: Mon, 24 Jun 2013 14:08:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, June 20, 2013 7:10:59 AM UTC-7, Sanjay Parekh wrote:
> On Wednesday, June 19, 2013 11:13:52 AM UTC-7, Sanjay Parekh wrote:
>=20
> > On Tuesday, June 18, 2013 10:06:32 AM UTC-7, Kevin Neilson wrote:
>=20
> >=20
>=20
> > > I discovered one cause (but not all) of the coredumps I experience.  =
If I had mismatched port widths in a VHDL instantiation, I'll often have co=
redumps.  There is no indication of what is wrong, but now I know what to l=
ook for in some cases.  I also suffer all kinds of problems when I try to u=
se unconstrained outputs based on unconstrained inputs, to the point where =
I just have to avoid that feature of VHDL.
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > I think it'd be great to have a cloud service you could use if you di=
dn't need to use it that often, but I don't know if that would be profitabl=
e for Mentor.
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > In my case, the tool choked miserably whenever I misinterpreted the sys=
temverilog spec and hooked up interfaces incorrectly. =20
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > In my opinion Mentor can use the cloud platform quite creatively and ma=
ke a business out of the unmet need which is allowing engineers to build my=
riad pieces of ip that serve niche areas without going through a vetting pr=
ocess to justify a big budget and therefore a big market.
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > And think of the community schools that generally offer programs in c p=
rogramming, etc.  Why not programs in verification, linting, scripting, sim=
ple designs, etc.? More side opportunities for consultants/senior engineers=
 as trainers, more opportunities for the students to learn online.  E.g. If=
 coursera/udemy can offer software courses, why not hardware courses as wel=
l?  And think of kickstarter/indiegogo which can fund those hardware projec=
ts.
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > Enough said.  I don't mean to say that cost of the tools is the only th=
ing that is preventing massive innovation in the hardware development.  But=
 I feel it is an important part as it limits the creative ability of the pe=
ople who can make a difference.
>=20
>=20
>=20
> Interesting read today if you can see as I do the opportunities for cloud=
 based tools.. http://gigaom.com/2013/06/19/open-compute-is-bringing-the-ma=
ker-movement-to-the-enterprise/?utm_source=3DGeneral+Users&utm_campaign=3D3=
472bd888e-c%3Atec%2Capl+d%3A06-20&utm_medium=3Demail&utm_term=3D0_1dd83065c=
6-3472bd888e-98983131

Aldec seems to get it.  So does Altera.  Read an interesting article today.=
  Looks cloud based tools are coming.  http://eecatalog.com/fpga/2013/02/06=
/practical-applications-of-cloud-computing-in-semiconductor-chip-design/

Article: 155368
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Mon, 24 Jun 2013 14:30:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
Verilog code for my Hive processor is now up:

http://opencores.org/project,hive

(Took me most of the freaking day to figure out SVN.)

Article: 155369
Subject: Re: Chasing Bugs in the Fog
From: Jon Elson <jmelson@wustl.edu>
Date: Mon, 24 Jun 2013 16:56:44 -0500
Links: << >>  << T >>  << A >>
rickman wrote:


> I didn't think it was in the VHDL because it had been simulated well and
> the nature of the bug is an occasional dropped character on the receive
> side.  Who can't design a UART?  Well, it could be in the handshake with
> the state machine, but still...
> 
Any time you recompile an FPGA and the problem disappears or
changes, it is a STRONG indication it is a timing problem.
Regenerating the place & route changes timings subtly between
sections, and may eliminate a marginal setup or hold time
problem.  You should make sure all signals that cross clock
boundaries are properly synchronized, and that you are giving the
right clock specification to your clocks in the ucf file.
If there are tricky timings on parts connected to the FPGA,
then you need to define the timings in the ucf file.

Jon

Article: 155370
Subject: Re: New soft processor core paper publisher?
From: Bakul Shah <usenet@bitblocks.com>
Date: Mon, 24 Jun 2013 15:03:38 -0700
Links: << >>  << T >>  << A >>
On 6/24/13 5:03 AM, Eric Wallin wrote:
> On Monday, June 24, 2013 3:24:44 AM UTC-4, Tom Gardner wrote:
>
>> Consider trying to pass a message consisting of one
>> integer from one thread to another such that the
>> receiving thread is guaranteed to be able to picks
>> it up exactly once.
>
> Thread A works on the integer value and when it is done it writes it to location Z.  It then reads a value at location X, increments it, and writes it back to location X.
>
> Thread B has been repeatedly reading location X and notices it has been incremented.  It reads the integer value at Z, performs some function on it, and writes it back to location Z.  It then reads a value at Y, increments it, and writes it back to location Y to let thread A know it took, worked on, and replaced the integer at Z.
>
> The above seems airtight to me if reads and writes to memory are not cached or otherwise delayed, and I don't see how interrupts are germane, but perhaps I haven't taken everything into account.
>

Consider a case where *both* thread A and B want to increment
a counter at location X? A reads X and finds it contains 10. But
before it can write back 11, B reads X and finds 10 and it too
writes back 11. Now you've lost a count. Can this happen in your
design? If so you need some sort of atomic update instruction.

Article: 155371
Subject: Re: New soft processor core paper publisher?
From: Eric Wallin <tammie.eric@gmail.com>
Date: Mon, 24 Jun 2013 15:23:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, June 24, 2013 6:03:38 PM UTC-4, Bakul Shah wrote:

> Consider a case where *both* thread A and B want to increment
> a counter at location X? A reads X and finds it contains 10. But
> before it can write back 11, B reads X and finds 10 and it too
> writes back 11. Now you've lost a count. Can this happen in your
> design? If so you need some sort of atomic update instruction.

It can happen if the programmer is crazy enough to do it, otherwise not.

Anyone have comments on my paper or the verilog?

Article: 155372
Subject: Re: Ask about finding maximum and second's maximum number in array is given.
From: jonesandy@comcast.net
Date: Mon, 24 Jun 2013 15:41:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
From a SW point of view, avoiding extra comparisons when not needed is valu=
able. From a HW point of view, that is not necessarily so. Unless the compa=
risons are (or can be) at different times and reuse the same comparison log=
ic, there is no benefit to avoiding a comparison if it might have to be don=
e. The logic to decide whether a comparison needs to be done needlessly add=
s to the complexity of the circuit.=20

Andy

Article: 155373
Subject: Re: New soft processor core paper publisher?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 24 Jun 2013 22:54:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
Bakul Shah <usenet@bitblocks.com> wrote:

(snip)
> Consider a case where *both* thread A and B want to increment
> a counter at location X? A reads X and finds it contains 10. But
> before it can write back 11, B reads X and finds 10 and it too
> writes back 11. Now you've lost a count. Can this happen in your
> design? If so you need some sort of atomic update instruction.

In the core memory days, there was a special solution.
Core read is destructive, so after reading the value out it has
to be restored. For read-modify-write instructions, one can avoid
the restore, and instead rewrite the new value. That assumes that
the instruction set has a read-modify-write instruction, a favorite
for DEC machines being increment and decrement.

DRAM also has descructive read, but except for the very early days,
I don't believe it has been used in that way. 

If the architecture does have a read-modify-write instruction,
such as increment, it can be designed such that no other thread
or I/O can come in between. 

-- glen


Article: 155374
Subject: Re: Ask about finding maximum and second's maximum number in array is given.
From: jonesandy@comcast.net
Date: Mon, 24 Jun 2013 15:57:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
I did not mean to imply that the implementation needed to use stacks, but t=
he card game usually would. In HW, only a single value ever need be retriev=
ed from a stack, so each stack is only one deep (a single register).

You may be right about the same or higher. The results are the same, but th=
is really depends on what one means by "2nd highest value": is it the secon=
d of the two highest values seen, or is it the second highest unique value?=
 If I draw two kings and a deuce, is the "second highest card" a king or a =
deuce?

Either comparison gives the same result, since if the 2nd king failed a hig=
her (only) comparison with 1st highest result, it would still pass the high=
er comparison with the 2nd. If you wanted to find the two highest unique va=
lues, more work would be required.

Andy



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search