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 158850

Article: 158850
Subject: Watchdog Timers for FPGA Designs
From: rickman <gnuarm@gmail.com>
Date: Wed, 11 May 2016 12:30:22 -0400
Links: << >>  << T >>  << A >>
A recent thread in comp.arch.embedded concerns using watchdog timers.  I 
made the point that they are used with software designs because of the 
many possible ways they can screw up while hardware designs tend to be 
less prone to failures that would require the use of a watchdog timer to 
restore operation.  This of course does not include designs that are 
subject to single event upset (SEU) such as space flight.

Opinions?  Anyone here use watchdogs and care to share examples?

Anyone seen an ASIC that used a watchdog to get it out of a stuck state? 
  That would include a CPU monitoring behavior and giving the ASIC a 
swift kick in the reset.

One point I was challenged on was that every FSM has potential for 
locking up and if it can't be designed to preclude that an internal 
watchdog would reset the FSM.  I don't agree that this is "always" 
needed, but if the protocol specifies a timeout, then this is part of 
the protocol and not a "watchdog" in a true sense looking for aberrant 
behavior.

-- 

Rick C

Article: 158851
Subject: Re: Watchdog Timers for FPGA Designs
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 11 May 2016 13:46:23 -0500
Links: << >>  << T >>  << A >>
rickman wrote:

> A recent thread in comp.arch.embedded concerns using watchdog timers.  I
> made the point that they are used with software designs because of the
> many possible ways they can screw up while hardware designs tend to be
> less prone to failures that would require the use of a watchdog timer to
> restore operation.  This of course does not include designs that are
> subject to single event upset (SEU) such as space flight.
> 
> Opinions?  Anyone here use watchdogs and care to share examples?
> 
I make a line of motion control interfaces.  all of them have a problem that 
if the CPU stops talking to them, they'd just keep commanding motion at the 
same speed.  One uses analog velocity outputs, so even if the local crystal 
oscillator stopped, it would keep that analog voltage going to the servo 
amp.  If the oscillator stopped, then any kind of digital watchdog would 
never trip.  So, I used an external one-shot and "non-clocked" logic to trip 
the E-stop FF to go into E-stop.  That clears the DAC registers to zero 
Volts and shuts down the digital outputs that may enable servo amps, spindle 
motors, etc.

When I say "non-clocked" above, I am referring to SR FFs and such latch-like 
constructs, so they are expected to work without a system clock.

Jon

Article: 158852
Subject: Re: Watchdog Timers for FPGA Designs
From: rickman <gnuarm@gmail.com>
Date: Wed, 11 May 2016 15:04:20 -0400
Links: << >>  << T >>  << A >>
On 5/11/2016 2:46 PM, Jon Elson wrote:
> rickman wrote:
>
>> A recent thread in comp.arch.embedded concerns using watchdog timers.  I
>> made the point that they are used with software designs because of the
>> many possible ways they can screw up while hardware designs tend to be
>> less prone to failures that would require the use of a watchdog timer to
>> restore operation.  This of course does not include designs that are
>> subject to single event upset (SEU) such as space flight.
>>
>> Opinions?  Anyone here use watchdogs and care to share examples?
>>
> I make a line of motion control interfaces.  all of them have a problem that
> if the CPU stops talking to them, they'd just keep commanding motion at the
> same speed.  One uses analog velocity outputs, so even if the local crystal
> oscillator stopped, it would keep that analog voltage going to the servo
> amp.  If the oscillator stopped, then any kind of digital watchdog would
> never trip.  So, I used an external one-shot and "non-clocked" logic to trip
> the E-stop FF to go into E-stop.  That clears the DAC registers to zero
> Volts and shuts down the digital outputs that may enable servo amps, spindle
> motors, etc.
>
> When I say "non-clocked" above, I am referring to SR FFs and such latch-like
> constructs, so they are expected to work without a system clock.

If I understand, your watchdog is not specific to the FPGA, but is a 
system watchdog in case of failure anywhere in the system, right?  Have 
you seen the oscillator stop on a board?  I don't have much experience 
with clocks faulting in the field, but obviously it is important to 
protect against any failure.

The other conversation I had in c.a.e is making me wonder if anyone has 
enough mistrust of their FPGA to add a watchdog in case a design fault 
causes a problem.  SEU is very uncommon unless you are in a high 
radiation environment.  There are always power supply glitches which can 
upset an FPGA, especially the RAM based types.  But do designers worry 
about design flaws in HDL?  Any examples of design mistakes you wish to 
protect from that a watchdog is useful?

-- 

Rick C

Article: 158853
Subject: Re: Matlab-to-Gates for Xilinx
From: wzab01@gmail.com
Date: Wed, 11 May 2016 14:23:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
W dniu poniedzia=C5=82ek, 9 maja 2016 19:31:25 UTC+2 u=C5=BCytkownik Kevin =
Neilson napisa=C5=82:
> I meant *code* conversion, not Simulink (schematic) conversion.

So sorry, I'm not aware of availability of such tool now.
For C written algorithms you may use their HLS.
I've used it a little, and it does its job, however the generated code is o=
bviously not intended to be human-legible ;-).
The generated code is usually better (in terms of logic consumption and max=
imum clock frequency) than my "quick&dirty" VHDL solutions, but slightly wo=
rse then "thoroughly handcrafted" VHDL.

Regards,
Wojtek

Article: 158854
Subject: Re: Watchdog Timers for FPGA Designs
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Wed, 11 May 2016 22:41:47 +0100
Links: << >>  << T >>  << A >>
On 11/05/16 17:30, rickman wrote:
> A recent thread in comp.arch.embedded concerns using watchdog timers.  I made
> the point that they are used with software designs because of the many possible
> ways they can screw up while hardware designs tend to be less prone to failures
> that would require the use of a watchdog timer to restore operation.  This of
> course does not include designs that are subject to single event upset (SEU)
> such as space flight.
>
> Opinions?  Anyone here use watchdogs and care to share examples?
>
> Anyone seen an ASIC that used a watchdog to get it out of a stuck state?  That
> would include a CPU monitoring behavior and giving the ASIC a swift kick in the
> reset.
>
> One point I was challenged on was that every FSM has potential for locking up
> and if it can't be designed to preclude that an internal watchdog would reset
> the FSM.  I don't agree that this is "always" needed, but if the protocol
> specifies a timeout, then this is part of the protocol and not a "watchdog" in a
> true sense looking for aberrant behavior.
>


I was once called in to fault-find a system that turned 18" pipes
into very interesting and pretty shapes. Every now and then the
controller would become catatonic and a /large/ lump of metal would
zoom off at ~1m/s - until the Big Red Switch was kicked.

The source turned out to be an infrequent hardware static-1 hazard
glitch. My recommendations were to fix the specific fault and also
to implement a hardware watchdog timer.

Yes, that was a design fault, and could have been trapped during
a design review - but it wasn't. Where all available people are
operating in new areas, there is a significant chance that design
faults will slip through despite everybody's best intentions.

Hence, in practice, it is unduly optimistic to say watchdog
timers aren't necessary because design rules are /sufficient/
to prevent design errors.

And we should, of course, always consider that equipment may not
be installed correctly, and/or an installation can degrade over
time.

Watchdog timers can be a useful last line of defence against
such events.

Article: 158855
Subject: Re: Watchdog Timers for FPGA Designs
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 11 May 2016 17:02:38 -0500
Links: << >>  << T >>  << A >>
rickman wrote:


> If I understand, your watchdog is not specific to the FPGA, but is a
> system watchdog in case of failure anywhere in the system, right?  Have
> you seen the oscillator stop on a board?  I don't have much experience
> with clocks faulting in the field, but obviously it is important to
> protect against any failure.
> 
Well, to protect against as many as can be done, practically.  A guy I knew 
a long time ago was given the task of finding ALL single points of failure 
in a large central office telephone switch.  They had two lockstep parallel 
CPUs and a hang detector.  There was a complicated network to provide a 
glitch-free changeover if the master clock source failed.  No matter how 
hard the design engineer tried, my friend always found there was STILL a 
single point of failure that would leave the system with no clock.
There were a bunch of other single points of failure in the system.

So, I'm just trying to cover as many cases as I can with simple logic.  The 
watchdog was much more aimed at computer or communication failure than a 
clock stoppage, but this logic should handle both cases.

In my case, all I want is a reliable halt to all motion, and don't care 
about automatic recovery.

> The other conversation I had in c.a.e is making me wonder if anyone has
> enough mistrust of their FPGA to add a watchdog in case a design fault
> causes a problem.  SEU is very uncommon unless you are in a high
> radiation environment.  There are always power supply glitches which can
> upset an FPGA, especially the RAM based types.  But do designers worry
> about design flaws in HDL?  Any examples of design mistakes you wish to
> protect from that a watchdog is useful?
> 
Yes, I did a little motion control thing that was supposed to shuttle a rack 
of samples back and forth, and it was going to be in an area where people 
access would be restricted, so we wanted it to try to muddle through even 
when something went wrong.  I added a few lines of VHDL here and there to 
try to trap abnormal cases that "should never happen" and go to the main 
reset condition and keep running.  These are standard practices, such as a 
binary-coded state machine, where all unused states explicitly go to a 
defined state.

Jon

Article: 158856
Subject: Problem with AXI4 Lite in Cyclone V
From: wzab01@gmail.com
Date: Wed, 11 May 2016 16:36:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I have created a simple AXI4-Lite slave, which works perfectly in Xilinx Zynq FPGA.
Unfortunately, the same design ported to Altera Cyclone V SoC behaves in a very strange way.
The write operations work good.
The read operation causes the ARM to hang.
Checking the transaction with the Signal Tap I can see, that my core receives 
ARVALID and responds with data and ARREADY it also receives RREADY and responds with RVALID. However, after that there is no further activity from the CPU.

The sources and waveforms are available at http://www.alteraforum.com/forum/showthread.php?t=52272 

Has anybody had similar problem with strange behaviour of AXI in Altera SoC?
May be I have to configure some magic register to be able to perform read?
However the Avalon slave, which is connected (in Qsys) to the same AXI4-Lite master works correctly...

I'll appreciate any suggestions how to debug that strange problem...
With best regards,
Wojtek

Article: 158857
Subject: Re: Watchdog Timers for FPGA Designs
From: rickman <gnuarm@gmail.com>
Date: Thu, 12 May 2016 00:55:33 -0400
Links: << >>  << T >>  << A >>
On 5/11/2016 5:41 PM, Tom Gardner wrote:
> On 11/05/16 17:30, rickman wrote:
>> A recent thread in comp.arch.embedded concerns using watchdog timers.
>> I made
>> the point that they are used with software designs because of the many
>> possible
>> ways they can screw up while hardware designs tend to be less prone to
>> failures
>> that would require the use of a watchdog timer to restore operation.
>> This of
>> course does not include designs that are subject to single event upset
>> (SEU)
>> such as space flight.
>>
>> Opinions?  Anyone here use watchdogs and care to share examples?
>>
>> Anyone seen an ASIC that used a watchdog to get it out of a stuck
>> state?  That
>> would include a CPU monitoring behavior and giving the ASIC a swift
>> kick in the
>> reset.
>>
>> One point I was challenged on was that every FSM has potential for
>> locking up
>> and if it can't be designed to preclude that an internal watchdog
>> would reset
>> the FSM.  I don't agree that this is "always" needed, but if the protocol
>> specifies a timeout, then this is part of the protocol and not a
>> "watchdog" in a
>> true sense looking for aberrant behavior.
>>
>
>
> I was once called in to fault-find a system that turned 18" pipes
> into very interesting and pretty shapes. Every now and then the
> controller would become catatonic and a /large/ lump of metal would
> zoom off at ~1m/s - until the Big Red Switch was kicked.
>
> The source turned out to be an infrequent hardware static-1 hazard
> glitch. My recommendations were to fix the specific fault and also
> to implement a hardware watchdog timer.

Interesting.  I learned that synchronous logic was used to provide 
outputs that needed to not change state with changing inputs that were 
stable within the setup time of the circuit.  It can be hard to produce 
combinatorial logic without static hazards, so they should not be 
attempted without formal analysis of the final circuit.


> Yes, that was a design fault, and could have been trapped during
> a design review - but it wasn't. Where all available people are
> operating in new areas, there is a significant chance that design
> faults will slip through despite everybody's best intentions.

So how did the watchdog work?


> Hence, in practice, it is unduly optimistic to say watchdog
> timers aren't necessary because design rules are /sufficient/
> to prevent design errors.
>
> And we should, of course, always consider that equipment may not
> be installed correctly, and/or an installation can degrade over
> time.
>
> Watchdog timers can be a useful last line of defence against
> such events.


-- 

Rick C

Article: 158858
Subject: Re: Watchdog Timers for FPGA Designs
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 12 May 2016 09:32:14 +0100
Links: << >>  << T >>  << A >>
On 12/05/16 05:55, rickman wrote:
> On 5/11/2016 5:41 PM, Tom Gardner wrote:
>> I was once called in to fault-find a system that turned 18" pipes
>> into very interesting and pretty shapes. Every now and then the
>> controller would become catatonic and a /large/ lump of metal would
>> zoom off at ~1m/s - until the Big Red Switch was kicked.
>>
>> The source turned out to be an infrequent hardware static-1 hazard
>> glitch. My recommendations were to fix the specific fault and also
>> to implement a hardware watchdog timer.
>
> Interesting.  I learned that synchronous logic was used to provide outputs that
> needed to not change state with changing inputs that were stable within the
> setup time of the circuit.  It can be hard to produce combinatorial logic
> without static hazards, so they should not be attempted without formal analysis
> of the final circuit.
>
>
>> Yes, that was a design fault, and could have been trapped during
>> a design review - but it wasn't. Where all available people are
>> operating in new areas, there is a significant chance that design
>> faults will slip through despite everybody's best intentions.
>
> So how did the watchdog work?

The company didn't want to pay me to design it for them. I have
no idea what they did/didn't do after my three days were up!


Article: 158859
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 12 May 2016 04:19:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:
> I have been in contact with Amanda from their sales department.
> They are unwilling to sell me a single board with hardware
> interface because I am not a company, and do not / will not
> have volume throughput. However, I have also found out they
> sell a Soft x86 IP Core which is for Altera FPGAs, so I am
> finding out if they will sell me a copy of that core or not, and
> how much it costs.
>
> Now, off to pray... :-)

Amanda contacted me today, and said the cost of obtaining their soft
x86 IP core, which is comprised of an Altera compatible project files,
and associated logic for the i386 CPU, would be $250,000 and up, and
would have a lead time of three to six months.

I wanted to find out if you think this is a valid quote or not?  (Given
the fact that open source x86 cores capable of booting Windows
exist):

    https://github.com/alfikpl/ao486 

Best regards,
Rick C. Hodgin

Article: 158860
Subject: Re: Problem with AXI4 Lite in Cyclone V
From: Alan Reynolds <abreynolds@me.com>
Date: Thu, 12 May 2016 09:26:06 -0400
Links: << >>  << T >>  << A >>
On 2016-05-11 23:36:14 +0000, wzab01@gmail.com said:

> Hi,
> 
> I have created a simple AXI4-Lite slave, which works perfectly in 
> Xilinx Zynq FPGA.
> Unfortunately, the same design ported to Altera Cyclone V SoC behaves 
> in a very strange way.
> The write operations work good.
> The read operation causes the ARM to hang.
> Checking the transaction with the Signal Tap I can see, that my core receives
> ARVALID and responds with data and ARREADY it also receives RREADY and 
> responds with RVALID. However, after that there is no further activity 
> from the CPU.
> 
> The sources and waveforms are available at 
> http://www.alteraforum.com/forum/showthread.php?t=52272
> 
> Has anybody had similar problem with strange behaviour of AXI in Altera SoC?
> May be I have to configure some magic register to be able to perform read?
> However the Avalon slave, which is connected (in Qsys) to the same 
> AXI4-Lite master works correctly...
> 
> I'll appreciate any suggestions how to debug that strange problem...
> With best regards,
> Wojtek

How did you integrate your AXI slave into the Qsys description?

You can look at the translated Avalon transactions on the AXI bus and 
compare them to yours to see what may be causing the problem.


Article: 158861
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 12 May 2016 06:49:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, May 12, 2016 at 7:19:08 AM UTC-4, Rick C. Hodgin wrote:
> Rick C. Hodgin wrote:
> > I have been in contact with Amanda from their sales department.
> > They are unwilling to sell me a single board with hardware
> > interface because I am not a company, and do not / will not
> > have volume throughput. However, I have also found out they
> > sell a Soft x86 IP Core which is for Altera FPGAs, so I am
> > finding out if they will sell me a copy of that core or not, and
> > how much it costs.
> >
> > Now, off to pray... :-)
> 
> Amanda contacted me today, and said the cost of obtaining their soft
> x86 IP core, which is comprised of an Altera compatible project files,
> and associated logic for the i386 CPU, would be $250,000 and up, and
> would have a lead time of three to six months.
> 
> I wanted to find out if you think this is a valid quote or not?  (Given
> the fact that open source x86 cores capable of booting Windows
> exist):
> 
>     https://github.com/alfikpl/ao486 

I had asked them in email if they'd ever designed an 80386 core or not,
and if the product had a proven track use record.

I received a reply from an application engineer at Force Technologies.
He reported they have not yet designed an 80386, but only an 80186 and
80286.

I have replied that I intend to write an 80386 compatible core using
my Logician tool, which will compile down to Verilog and can be used in
an Altera FPGA project file.  I have offered to give them a free IP
license once it is completed so they can have the product, and possibly
pass along savings to other would-be customers.

Best regards,
Rick C. Hodgin

Article: 158862
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 12 May 2016 09:21:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, May 12, 2016 at 7:19:08 AM UTC-4, Rick C. Hodgin wrote:
> I wanted to find out if you think this is a valid quote or not?
I have no reason to doubt that it is a valid quote.

Kevin

Article: 158863
Subject: Re: Problem with AXI4 Lite in Cyclone V
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Thu, 12 May 2016 16:51:21 -0000 (UTC)
Links: << >>  << T >>  << A >>
wzab01@gmail.com wrote:

> Hi,
>
> I have created a simple AXI4-Lite slave, which works perfectly in Xilinx Zynq FPGA.
> Unfortunately, the same design ported to Altera Cyclone V SoC behaves in a very strange way.
> The write operations work good.
> The read operation causes the ARM to hang.
> Checking the transaction with the Signal Tap I can see, that my core receives 
> ARVALID and responds with data and ARREADY it also receives RREADY and responds with RVALID. However, after that there is no further activity from the CPU.
>
> The sources and waveforms are available at http://www.alteraforum.com/forum/showthread.php?t=52272 
>
> Has anybody had similar problem with strange behaviour of AXI in Altera SoC?
> May be I have to configure some magic register to be able to perform read?
> However the Avalon slave, which is connected (in Qsys) to the same AXI4-Lite master works correctly...
>
> I'll appreciate any suggestions how to debug that strange problem...
> With best regards,
> Wojtek

I haven't read your sources, but you said one thing there that could be
it:

> also receives RREADY and responds with RVALID.

If that's really the case then no, bad designer, no cookie.  AXI is very
explicitly not allowed to make VALID conditional on READY.  Since it
looks from those timing diagrams like you're setting it combinationally
that could be the source of your problems.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 158864
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: David Brown <david.brown@hesbynett.no>
Date: Fri, 13 May 2016 09:16:55 +0200
Links: << >>  << T >>  << A >>
On 12/05/16 13:19, Rick C. Hodgin wrote:
> Rick C. Hodgin wrote:
>> I have been in contact with Amanda from their sales department.
>> They are unwilling to sell me a single board with hardware
>> interface because I am not a company, and do not / will not
>> have volume throughput. However, I have also found out they
>> sell a Soft x86 IP Core which is for Altera FPGAs, so I am
>> finding out if they will sell me a copy of that core or not, and
>> how much it costs.
>>
>> Now, off to pray... :-)
> 
> Amanda contacted me today, and said the cost of obtaining their soft
> x86 IP core, which is comprised of an Altera compatible project files,
> and associated logic for the i386 CPU, would be $250,000 and up, and
> would have a lead time of three to six months.
> 
> I wanted to find out if you think this is a valid quote or not?  (Given
> the fact that open source x86 cores capable of booting Windows
> exist):
> 
>     https://github.com/alfikpl/ao486 
> 

I have little experience with the price of FPGA IP cores, but given the
types of prices for commonly used but much simpler cores such as fast
memory controllers or Ethernet devices, this sounds like a bargain.  We
are talking about a very complex core with a very small customer base to
spread development costs, customised for your use, with documentation,
support, testing, and everything else involved in a serious and
professional core.

The only surprising thing here is that they have given you permission to
publish this pricing information publicly on the net - usually these
sorts of things are confidential because they can vary significantly
between customers according to the exact requirements.  If they wanted
their pricing to be public, they would have published figures on their
website.



Article: 158865
Subject: FPGA boards in egypt
From: aymanmimomimomimo@gmail.com
Date: Fri, 13 May 2016 04:57:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Plz I want to buy FPGA boards for my graduation project and l don't know where can I get it from Egypt (FPGA spartan 6 sp601 or sp605)

Article: 158866
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 13 May 2016 05:20:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, May 13, 2016 at 3:16:58 AM UTC-4, David Brown wrote:
> [snip]

The type and manner of seeds we sow reap their harvest in due season, David.
I advise that you quickly change seeds.

Best regards,
Rick C. Hodgin

Article: 158867
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: David Brown <david.brown@hesbynett.no>
Date: Fri, 13 May 2016 14:42:41 +0200
Links: << >>  << T >>  << A >>
On 13/05/16 14:20, Rick C. Hodgin wrote:
> On Friday, May 13, 2016 at 3:16:58 AM UTC-4, David Brown wrote:
>> [snip]
> 
> The type and manner of seeds we sow reap their harvest in due season, David.
> I advise that you quickly change seeds.
> 

What on earth does that mean?  If you trying to say that you did not
like something I wrote, then it would make a lot more sense to quote the
part you didn't like, and then explain why you didn't like it.  If I
have written something that is incorrect, or written in a way that is
causing upset or insult, then I would rather hear the actual complaint.
 That way I can either justify or defend my viewpoint, or correct it, or
apologise, as appropriate.  Suggesting that I "change my seeds" doesn't
help anyone.  I can only assume that it is some weird religious
reference, and we all know how little respect anyone has for your
peculiar ideas in that area.

At a guess, your issue is my point that companies that provide
individual quotations tailored for individual customers, rather than
publicly viewable standardised price lists, prefer to keep these
quotations private.  This is common practice - though I fully understand
if you don't like it.  In particular, if the quotation is restricted as
confidential information, you cannot do, as you did, publish it and ask
for opinions.  But it is also quite possible - if surprising - that this
supplier does not consider the quotation to be privileged information
and are happy to see it published.  My comment is therefore to encourage
you to check the situation, and be sure you are not breaking any
agreements or contracts with what you post, as that would surely
jeopardise your relationships with this company.





Article: 158868
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 13 May 2016 05:48:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, May 13, 2016 at 8:42:44 AM UTC-4, David Brown wrote:
> [snip]

Have you read the New Testament as an adult?  Have you considered the
possibility that you may be on the wrong path in life (not with your
career or worldly things, but with eternal things)?

There are some questions you need to ask yourself, and seek answers
on.  If you're willing to do this, then you will inherently know what
I mean.  But if you are unwilling, you will never understand anything
I write toward those ends.

-----
David, you're an extremely knowledgeable man.  Don't miss out on this
teaching.  Learn more than you know today.  It will benefit all areas
of your life.

Best regards,
Rick C. Hodgin

Article: 158869
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Fri, 13 May 2016 14:19:29 +0100
Links: << >>  << T >>  << A >>
On 13/05/16 13:48, Rick C. Hodgin wrote:
>[snip]

I disagree with your third point.


Article: 158870
Subject: Re: Problem with AXI4 Lite in Cyclone V
From: wzab01@gmail.com
Date: Fri, 13 May 2016 06:25:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
W dniu czwartek, 12 maja 2016 18:54:56 UTC+2 u=C5=BCytkownik Rob Gaddi napi=
sa=C5=82:
> wzab01@gmail.com wrote:
>=20
> > Hi,
> >
> > I have created a simple AXI4-Lite slave, which works perfectly in Xilin=
x Zynq FPGA.
> > Unfortunately, the same design ported to Altera Cyclone V SoC behaves i=
n a very strange way.
> > The write operations work good.
> > The read operation causes the ARM to hang.
> > Checking the transaction with the Signal Tap I can see, that my core re=
ceives=20
> > ARVALID and responds with data and ARREADY it also receives RREADY and =
responds with RVALID. However, after that there is no further activity from=
 the CPU.
> >
> > The sources and waveforms are available at http://www.alteraforum.com/f=
orum/showthread.php?t=3D52272=20
> >
> > Has anybody had similar problem with strange behaviour of AXI in Altera=
 SoC?
> > May be I have to configure some magic register to be able to perform re=
ad?
> > However the Avalon slave, which is connected (in Qsys) to the same AXI4=
-Lite master works correctly...
> >
> > I'll appreciate any suggestions how to debug that strange problem...
> > With best regards,
> > Wojtek
>=20
> I haven't read your sources, but you said one thing there that could be
> it:
>=20
> > also receives RREADY and responds with RVALID.
>=20
> If that's really the case then no, bad designer, no cookie.  AXI is very
> explicitly not allowed to make VALID conditional on READY.  Since it
> looks from those timing diagrams like you're setting it combinationally
> that could be the source of your problems.
>=20

Yes you are right. I've spent quite a long time implementing my core to ens=
ure that this condition is met and RVALID may be issued possibly before RRE=
ADY without adding unnecessary wait cycles when RREADY is already set.

The code is OK. I simply tried to make description in the post too simple.

In fact what my code does is in case of read transaction is:
1. Assert RVALID
2. If RREADY is '1', consider transaction to be finished.
   If RREADY is '0', set the flag denoting, that in the next cycle you have=
 to wait for RREADY

Anyway if it was that problem, my core would be waiting forever for RREADY.=
 In fact issued RVALID, in the same cycle I get RREADY, but the transaction=
 is not properly terminated.

BTW. The code is available either on the Altera forum or in IPbus track: ht=
tps://svnweb.cern.ch/trac/cactus/ticket/1876

With best reagards,
Wojtek

Article: 158871
Subject: Problem if compilation order in OOC compilations in Xilinx Vivado
From: wzab01@gmail.com
Date: Fri, 13 May 2016 06:47:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Has anybody in this group faced the problem of incorrect compilation order =
of blocks selected for Out-of-context (OOC) compilation?
It works correctly in case of blocks converted into packaged IP-cores.
However very often in the huge projects I'm dealing with (e.g. using the 70=
% of Virtex 7 xc7vx690tffg1927) I want to split the design into blocks synt=
hesized separately without packaging them.

It allows to avoid resynthesizing of the whole design (which takes from 5 t=
o 8 hours) when only one of the blocks is modified.

The reason to not package them is the fact that the design is implemented i=
n high level VHDL. The ports of the components are usually implemented as r=
ecords describing the data structures. The current packaging standards base=
d oon IP-XACT do not support such ports.

Anyway, I'm quite happy with using OOC synthesis for my components (Yes, yo=
u can do it even for blocks with ports of user defined types as long as you=
 provide your own stubs instead of letting Vivado to generate them automati=
cally).=20
However, there is one HUGE problem.

The "OOC Module Runs" are performed perfectly, and the separate modules are=
 synthesized correctly, but as soon as I start the main (usually "synth_1")=
 run, all OOC runs are set "out-of-date" and restarted. This time they are =
synthesized using incorrect compilation order which results in compilation =
errors (typically entities using types and constants defined in the package=
s are compiled before those packages).

After some research I've found an work-around, which can be even implemente=
d in the Tcl script.
I've described the whole problem together with a "bug reproducer" and worka=
round on the Xilinx forum - https://forums.xilinx.com/t5/Synthesis/Vivado-i=
ncorrect-automatic-compilation-order-in-OOC-synthesis/m-p/698402#M18253 but=
 up to know I didn't get any answer from Xilinx.

I'm quite surprised, that no one alse has reported this rather serious bug =
before.

AFAIK it was present at least in all 2015.x and 2016.1 versions. (I don't k=
now whether it was in the earlier versions, as it was begining of the 2015,=
 when I had to split my design into OOC blocks).

With best regards,
Wojtek

Article: 158872
Subject: Re: Using an FPGA to drive the 80386 CPU on a real motherboard
From: David Brown <david.brown@hesbynett.no>
Date: Fri, 13 May 2016 15:54:45 +0200
Links: << >>  << T >>  << A >>
On 13/05/16 15:49, rickman wrote:

> 
> It is bad enough that one person is polluting the group with totally off
> topic discussions.  Do we have to make it a group effort?
> 
> Why don't you exchange private email rather than public posts?  Then the
> rest of us don't need to see what is essentially a private conversation.
> 

Fair enough - sorry about that.  I don't usually reply much to Rick's
non-technical posts.

I don't plan on taking this any further (in the group, or in email).


Article: 158873
Subject: Re: FPGA boards in egypt
From: rickman <gnuarm@gmail.com>
Date: Fri, 13 May 2016 10:23:59 -0400
Links: << >>  << T >>  << A >>
On 5/13/2016 7:57 AM, aymanmimomimomimo@gmail.com wrote:
> Plz I want to buy FPGA boards for my graduation project and l don't know where can I get it from Egypt (FPGA spartan 6 sp601 or sp605)

FPGA devices seldom stand alone.  The board you choose will likely 
depend on what you wish to do with it and so the other devices you need 
on the same board.

So what do you want to do in this project?

Just for grins, here is a fairly low cost board.

http://www.digikey.com/short/3pjct2

BTW, I can't find any reference in the data sheet to SP601 or SP605. 
What does that mean?

-- 

Rick C

Article: 158874
Subject: Re: FPGA boards in egypt
From: colin <colin_toogood@yahoo.com>
Date: Fri, 13 May 2016 07:38:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm not sure why you aren't doing this through the University access program.

EBAY is often your friend. A guy is selling nine SP601s right now but you will not like the price. When you realize that you can fit one man years worth of VHDL in a Spartan 3 you might re-think and they come up fairly often.

Colin



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