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 156125

Article: 156125
Subject: Re: microZed adventures
From: Przemek Klosowski <przemek@tux.dot.org>
Date: Thu, 5 Dec 2013 04:44:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Fri, 22 Nov 2013 19:33:38 +0000, Jan Panteltje wrote:

> but I can flip 10M Hz that makes 50 nS on 50 nS off on the Raspi,
> without any FPGA, using GPIO.

Beagleboards use TI AM335x which has two PRU units: embedded simple CPUs 
that run at 200MHz and execute programs from a memory area that can be 
accessed (for data and/or code) from the main ARM CPU.

Some I/O pins are directly accessible from the PRU and others go through 
the general IO. In theory the former can be flipped every 5 ns---in 
practice Charlie Steinhauer discovered pipeline effects that limit it 
somehow, but still, you can get a good fraction of 100MHz.

Article: 156126
Subject: Re: LCD test on Spartan 3E FPGA
From: Tung Thanh Le <ttungl@gmail.com>
Date: Thu, 5 Dec 2013 16:57:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, November 27, 2013 3:53:39 PM UTC-6, Stef wrote:
> In comp.arch.fpga,
>=20
> Tung Thanh Le <ttungl@gmail.com> wrote:
>=20
> > On Wednesday, November 27, 2013 10:00:37 AM UTC-6, Stef wrote:
>=20
> >> In comp.arch.fpga,
>=20
> >>=20
>=20
> >> Tung Thanh Le <ttungl@gmail.com> wrote:
>=20
> >>=20
>=20
> >> > Hi,
>=20
> >>=20
>=20
> >> >    I got a problem that I cannot understand how to display on the LC=
D of Spartan 3E FPGA. Then, how to get the inputs and outputs of a 16-bit R=
ipple Carry Adder  to show on LCD? Please any one who has known/dealt with =
this problem, just let me know. I appreciate that. Thanks.
>=20
> >>=20
>=20
> >>=20
>=20
> >>=20
>=20
> >> To my knowledge there is no Spartan 3E FPGA with built-in LCD. So you
>=20
> >> probably have a board with a Spartan, an LCD and possibly other stuff.
>=20
> >> To get some more meaningfull answers, you'll have to tell us some
>=20
> >> details of the board you are using. What kind of LCD, how is it
>=20
> >> connected to the Spartan, that sort of info.
>=20
> >>=20
>=20
> >>=20
>=20
> >> It would also be appreciated if you tell us more about the context of
>=20
> >> your question. Homework? Commercial? Hobby? Other?
>=20
> =20
>=20
> >    Thank you for your reply. I am using Spartan 3E Starter Kit with LCD=
 control. The thing that I am not familiar with this kind of indirect contr=
ol LCD through its KCPSM3. This is the material links, please take a look a=
t this and please let me know how to cope with the LCD. Thanks.
>=20
> > https://www.dropbox.com/s/0nhp177502ka4ir/Spartan-3EManual%20-%20FPGA%2=
0starter%20kit%20board%20user%20guide.pdf
>=20
>=20
>=20
> OK you're using the Spartan-3E starter kit and want to use its on-board
>=20
> LCD.
>=20
>=20
>=20
> Lots of info on the LCD and how to interface to it in chapter 5, what
>=20
> are you missing?
>=20
>=20
>=20
> > https://www.dropbox.com/s/tkxtx3p3mqr0ook/s3esk_startup.pdf
>=20
>=20
>=20
> This is a complete example of using the LCD with the picoblaze softcore.
>=20
> If you intend to use picoblaze, just use the example and build from there=
.
>=20
> If you don't want to use picoblaze, but do everything directly in logic,
>=20
> there is still a lot of valuable information in that document. But you=20
>=20
> have to replace the code parts with logic (state machine) that performs
>=20
> the transfers described.
>=20
>=20
>=20
> And for your counter question, you'll have to add the counter and logic
>=20
> to encode the value in the format you wish to show on the LCD.
>=20
>=20
>=20
> --=20
>=20
> Stef    (remove caps, dashes and .invalid from e-mail address to reply by=
 mail)
>=20
>=20
>=20
> Harp not on that string.
>=20
> 		-- William Shakespeare, "Henry VI"

Dear Stef,
   Thank you very much for your reply. I got the point for solving this pro=
blem. Anyway, thank you.
Have a nice day,
Best regards,
Tung

Article: 156127
Subject: MachXO breakout board as a programmer
From: Gergo <beagyazottfejleszto@gmail.com>
Date: Sat, 7 Dec 2013 01:51:28 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi!

I'd like to use my MachXO Breakout Board as a programming device to program a custom MachXO chip on a board. Is that possible at all? I could not find anything useful in the board's user guide. Any tip would be highly appreciated!

G

Article: 156128
Subject: Implementing multiple interrupts
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Sat, 7 Dec 2013 12:04:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi all.

Some time ago, I designed a small and simple CPU to go into a project I 
am sort-of working on (when can I steal the time to do so). Now, I added 
an interrupt mechanism to it and encountered a problem when I tried to 
turn the one-interrupt interrupt into a multiple-interrupt interrupt - 
the kind all other CPUs have these days.

Here's my gripe: suppose the CPU enters interrupt 1. While it is 
interrupted, IRQ2 comes in. And then IRQ3 comes in, followed by IRQ4. WTF 
am I supposed to do now? I want all IRQ-s to be handled. So, no ignoring.

My first idea was to make a stack and push the interrupt contexts onto 
the stack as new IRQs come in and pop them as the software interrupt 
handlers return. But this is far too elaborate to be implemented in 
reasonably little resources.

My second idea was to have every IRQ assert a bit in a special reqister 
before asserting the unified IRQ signal. Then I would mandate that the 
software interrupt handler iterates over the register and handles IRQs 
that it finds asserted. And when it is done, the interrupt handler would 
reiterate over the register to catch any interrupts that came in during 
the handling of the previous ones. I currently plan to use a variant of 
this method.

While writing this I also came up with the option of deffering IRQs until 
the previous one's handling returns. Probably with some sort of a stack. 
If done correctly, it should take little resources.

What to other CPUs usualy do in these situations?

Article: 156129
Subject: Re: MachXO breakout board as a programmer
From: Gabor <gabor@szakacs.org>
Date: Sat, 07 Dec 2013 09:30:10 -0500
Links: << >>  << T >>  << A >>
On 12/7/2013 4:51 AM, Gergo wrote:
> Hi!
>
> I'd like to use my MachXO Breakout Board as a programming device to program a custom MachXO chip on a board. Is that possible at all? I could not find anything useful in the board's user guide. Any tip would be highly appreciated!
>
> G
>

Not familiar with that board, but if you have the schematic you could
see if the JTAG chain can be brought out to a connector.  You'd need to
break the path from TDO on the MachXO on board to the programmer and
insert your external device's TDI-->TDO in this path.

-- 
Gabor

Article: 156130
Subject: Re: Implementing multiple interrupts
From: Gabor <gabor@szakacs.org>
Date: Sat, 07 Dec 2013 09:44:57 -0500
Links: << >>  << T >>  << A >>
On 12/7/2013 7:04 AM, Aleksandar Kuktin wrote:
> Hi all.
>
> Some time ago, I designed a small and simple CPU to go into a project I
> am sort-of working on (when can I steal the time to do so). Now, I added
> an interrupt mechanism to it and encountered a problem when I tried to
> turn the one-interrupt interrupt into a multiple-interrupt interrupt -
> the kind all other CPUs have these days.
>
> Here's my gripe: suppose the CPU enters interrupt 1. While it is
> interrupted, IRQ2 comes in. And then IRQ3 comes in, followed by IRQ4. WTF
> am I supposed to do now? I want all IRQ-s to be handled. So, no ignoring.
>
> My first idea was to make a stack and push the interrupt contexts onto
> the stack as new IRQs come in and pop them as the software interrupt
> handlers return. But this is far too elaborate to be implemented in
> reasonably little resources.
>
> My second idea was to have every IRQ assert a bit in a special reqister
> before asserting the unified IRQ signal. Then I would mandate that the
> software interrupt handler iterates over the register and handles IRQs
> that it finds asserted. And when it is done, the interrupt handler would
> reiterate over the register to catch any interrupts that came in during
> the handling of the previous ones. I currently plan to use a variant of
> this method.
>
> While writing this I also came up with the option of deffering IRQs until
> the previous one's handling returns. Probably with some sort of a stack.
> If done correctly, it should take little resources.
>
> What to other CPUs usualy do in these situations?
>

Normally you have an instruction to mask / unmask interrupts.  When the
CPU gets interrupted, the source that caused the interrupt gets cleared,
but others may be active.  In some CPU's, there is one guaranteed
instruction before another can interrupt the CPU, and you must use
the general "mask interrupts" instruction as the first instruction
of the service routine.  Others automatically set the global interrupt
mask when the interrupt occurs, and the service routine only needs
to unmask them at the end of the routine, just before the return.  Note
that this means you need to allow one more instruction after the
unmask to make sure the return happens before the next interrupt,
or you can have stack overruns.  Another option is to have a
special RTI instruction that enables interrupts and returns.

In addition to this simple global mask, there is usually a mask
per IRQ, that allows you to have prioritized interrupts.  An
interrupt service routine in this case will first save the
current state of the per-IRQ mask, then mask all lower level
IRQ's and unmask interrupts globally.  Thus only higher-level
IRQ's can interrupt this service routine.  At the end, it must
restore the state of the per-IRQ masks.

All this implies a machine with a stack to save current state.
Here again there are differences in implementation.  Some
CPU's will automatically push registers onto the stack when
the interrupt occurs, others require the service routine
to save any state that it may change during operation.  In
the first case, you definitely need a separate RTI instruction
that unwinds the stack.

-- 
Gabor

Article: 156131
Subject: Re: Implementing multiple interrupts
From: Stephen Fuld <SFuld@alumni.cmu.edu.invalid>
Date: Sat, 07 Dec 2013 08:13:10 -0800
Links: << >>  << T >>  << A >>
On 12/7/2013 6:44 AM, Gabor wrote:
> On 12/7/2013 7:04 AM, Aleksandar Kuktin wrote:
>> Hi all.
>>
>> Some time ago, I designed a small and simple CPU to go into a project I
>> am sort-of working on (when can I steal the time to do so). Now, I added
>> an interrupt mechanism to it and encountered a problem when I tried to
>> turn the one-interrupt interrupt into a multiple-interrupt interrupt -
>> the kind all other CPUs have these days.
>>
>> Here's my gripe: suppose the CPU enters interrupt 1. While it is
>> interrupted, IRQ2 comes in. And then IRQ3 comes in, followed by IRQ4. WTF
>> am I supposed to do now? I want all IRQ-s to be handled. So, no ignoring.
>>
>> My first idea was to make a stack and push the interrupt contexts onto
>> the stack as new IRQs come in and pop them as the software interrupt
>> handlers return. But this is far too elaborate to be implemented in
>> reasonably little resources.
>>
>> My second idea was to have every IRQ assert a bit in a special reqister
>> before asserting the unified IRQ signal. Then I would mandate that the
>> software interrupt handler iterates over the register and handles IRQs
>> that it finds asserted. And when it is done, the interrupt handler would
>> reiterate over the register to catch any interrupts that came in during
>> the handling of the previous ones. I currently plan to use a variant of
>> this method.
>>
>> While writing this I also came up with the option of deffering IRQs until
>> the previous one's handling returns. Probably with some sort of a stack.
>> If done correctly, it should take little resources.
>>
>> What to other CPUs usualy do in these situations?
>>
>
> Normally you have an instruction to mask / unmask interrupts.  When the
> CPU gets interrupted, the source that caused the interrupt gets cleared,
> but others may be active.  In some CPU's, there is one guaranteed
> instruction before another can interrupt the CPU, and you must use
> the general "mask interrupts" instruction as the first instruction
> of the service routine.  Others automatically set the global interrupt
> mask when the interrupt occurs, and the service routine only needs
> to unmask them at the end of the routine, just before the return.  Note
> that this means you need to allow one more instruction after the
> unmask to make sure the return happens before the next interrupt,
> or you can have stack overruns.  Another option is to have a
> special RTI instruction that enables interrupts and returns.
>
> In addition to this simple global mask, there is usually a mask
> per IRQ, that allows you to have prioritized interrupts.  An
> interrupt service routine in this case will first save the
> current state of the per-IRQ mask, then mask all lower level
> IRQ's and unmask interrupts globally.  Thus only higher-level
> IRQ's can interrupt this service routine.  At the end, it must
> restore the state of the per-IRQ masks.
>
> All this implies a machine with a stack to save current state.
> Here again there are differences in implementation.  Some
> CPU's will automatically push registers onto the stack when
> the interrupt occurs, others require the service routine
> to save any state that it may change during operation.  In
> the first case, you definitely need a separate RTI instruction
> that unwinds the stack.

Yes.  All those will work.  Another alternative is to have another, 
probably smaller, register set that is used by the first level interrupt 
handler.  When an interrupt comes in, if it is allowed, further 
interrupts are disabled, the system is "switched" to use the special 
register set, and control is transferred to the ISR.  A minimal amount 
of code is executed to whatever is needed to save the details of the 
interrupt to memory, set flags, etc. Then a special instruction is 
executed (e.g. something like the RTI mentioned above) that returns to 
the instruction that would have been executed had the interrupt not 
occurred, further interrupts are enabled and the mode is switched back 
to the normal register set.  The big advantage of this is faster 
interrupt response, as no need to save/restore registers, and no need to 
size a specific interrupt stack.

There are lots of alternatives depending on your specific requirements 
and available resources.

The key requirement for all of them is the ability to defer interrupts 
for a short time until the information about an interrupt is saved.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

Article: 156132
Subject: Re: Implementing multiple interrupts
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 07 Dec 2013 20:26:26 +0000
Links: << >>  << T >>  << A >>
On 07/12/13 12:04, Aleksandar Kuktin wrote:
> Hi all.
>
> Some time ago, I designed a small and simple CPU to go into a project I
> am sort-of working on (when can I steal the time to do so). Now, I added
> an interrupt mechanism to it and encountered a problem when I tried to
> turn the one-interrupt interrupt into a multiple-interrupt interrupt -
> the kind all other CPUs have these days.
>
> Here's my gripe: suppose the CPU enters interrupt 1. While it is
> interrupted, IRQ2 comes in. And then IRQ3 comes in, followed by IRQ4. WTF
> am I supposed to do now? I want all IRQ-s to be handled. So, no ignoring.
>
> My first idea was to make a stack and push the interrupt contexts onto
> the stack as new IRQs come in and pop them as the software interrupt
> handlers return. But this is far too elaborate to be implemented in
> reasonably little resources.
>
> My second idea was to have every IRQ assert a bit in a special reqister
> before asserting the unified IRQ signal. Then I would mandate that the
> software interrupt handler iterates over the register and handles IRQs
> that it finds asserted. And when it is done, the interrupt handler would
> reiterate over the register to catch any interrupts that came in during
> the handling of the previous ones. I currently plan to use a variant of
> this method.
>
> While writing this I also came up with the option of deffering IRQs until
> the previous one's handling returns. Probably with some sort of a stack.
> If done correctly, it should take little resources.
>
> What to other CPUs usualy do in these situations?

Consider "level triggered" interrupts rather than edge
triggered interrupts...

Every peripheral (etc) generates an interrupt which pulls a
single signal high until that interrupt has been cleared
by the relevant interrupt service routine (ISR) and the return
from interrupt (RTI) instruction executed.

If a second interrupt arrives before the first one has been
cleared, then it too pulls the same signal high - which has
zero effect. When the ISR has cleared the first interrupt
and the RTI executed, the processor immediately enters
the ISR for the second interrupt.

Hence all the interrupts are dealt with serially without
preemption. If you want preemption then you have to design
a hierarchy of interrupts and be prepared to stack one
context for each level in the hierarchy. Many processors
manage with two levels, typically a maskable interrupt
and a non-maskable interrupt.

Have a look at early microprocessors, e.g. the Z80 or 6800.


Article: 156133
Subject: Re: Implementing multiple interrupts
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 7 Dec 2013 20:39:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Aleksandar Kuktin <akuktin@gmail.com> wrote:
 
> Some time ago, I designed a small and simple CPU to go into a project I 
> am sort-of working on (when can I steal the time to do so). Now, I added 
> an interrupt mechanism to it and encountered a problem when I tried to 
> turn the one-interrupt interrupt into a multiple-interrupt interrupt - 
> the kind all other CPUs have these days.
 
> Here's my gripe: suppose the CPU enters interrupt 1. While it is 
> interrupted, IRQ2 comes in. And then IRQ3 comes in, followed by IRQ4. WTF 
> am I supposed to do now? I want all IRQ-s to be handled. So, no ignoring.

First, you want level triggered interrupts, such that the interrupt
line stays active until acknowledged. This was a problem with the ISA
bus, fixed in PCI. 

Q-bus, and probably the somewhat similar unibus, use a daisy-chained
interrupt acknowledge system. You should probably look up the details,
but, more or less, it chains through the backplane slots, such that
ones nearer the CPU have higher priority. When not interrupting,
the board in each slot (or a jumper board if no actual board) passes
the ACK down the line. It a board has requested an interrupt, it doesn't
pass it along, and the CPU will then process that one. When it clears,
the next one will get its chance. Note the requirement for level 
triggering, and that the interrupt routine (or hardware) must reset
the interrupt line at the appropriate time.

-- glen

Article: 156134
Subject: Re: Implementing multiple interrupts
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 7 Dec 2013 22:55:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

(snip)

> Consider "level triggered" interrupts rather than edge
> triggered interrupts...

Yes.

> Every peripheral (etc) generates an interrupt which pulls a
> single signal high until that interrupt has been cleared
> by the relevant interrupt service routine (ISR) and the return
> from interrupt (RTI) instruction executed.

Normally low, at least in the TTL days. Many buses are based on TTL
level signals, even if implemented in MOS logic.  TTL outputs pull
down much harder than up.

-- glen

Article: 156135
Subject: Re: Implementing multiple interrupts
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 07 Dec 2013 23:38:36 +0000
Links: << >>  << T >>  << A >>
On 07/12/13 22:55, glen herrmannsfeldt wrote:
> In comp.arch.fpga Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>> Every peripheral (etc) generates an interrupt which pulls a
>> single signal high until that interrupt has been cleared
>> by the relevant interrupt service routine (ISR) and the return
>> from interrupt (RTI) instruction executed.
>
> Normally low, at least in the TTL days. Many buses are based on TTL
> level signals, even if implemented in MOS logic.  TTL outputs pull
> down much harder than up.

Yes indeed; I originally wrote "low". Given the modern
tendency for all i/o (and less obviously internal) signals
to be active-high, i suspected the OP wouldn't be familiar
with how to cheaply implement a wired-or function with
active-low signals. And I didn't see any benefit in explaining
he concept!

Active high i/o signals /still/ feel somewhat unnatural
to me. Must be too old :(

Article: 156136
Subject: Re: Implementing multiple interrupts
From: Gabor <gabor@szakacs.org>
Date: Sat, 07 Dec 2013 22:10:02 -0500
Links: << >>  << T >>  << A >>
On 12/7/2013 3:39 PM, glen herrmannsfeldt wrote:
> In comp.arch.fpga Aleksandar Kuktin <akuktin@gmail.com> wrote:
>
>> Some time ago, I designed a small and simple CPU to go into a project I
>> am sort-of working on (when can I steal the time to do so). Now, I added
>> an interrupt mechanism to it and encountered a problem when I tried to
>> turn the one-interrupt interrupt into a multiple-interrupt interrupt -
>> the kind all other CPUs have these days.
>
>> Here's my gripe: suppose the CPU enters interrupt 1. While it is
>> interrupted, IRQ2 comes in. And then IRQ3 comes in, followed by IRQ4. WTF
>> am I supposed to do now? I want all IRQ-s to be handled. So, no ignoring.
>
> First, you want level triggered interrupts, such that the interrupt
> line stays active until acknowledged. This was a problem with the ISA
> bus, fixed in PCI.
>
> Q-bus, and probably the somewhat similar unibus, use a daisy-chained
> interrupt acknowledge system. You should probably look up the details,
> but, more or less, it chains through the backplane slots, such that
> ones nearer the CPU have higher priority. When not interrupting,
> the board in each slot (or a jumper board if no actual board) passes
> the ACK down the line. It a board has requested an interrupt, it doesn't
> pass it along, and the CPU will then process that one. When it clears,
> the next one will get its chance. Note the requirement for level
> triggering, and that the interrupt routine (or hardware) must reset
> the interrupt line at the appropriate time.
>
> -- glen
>

The last time I designed a Unibus board, I needed to get the
bus pinout from an insider at DEC.  The documentation was
all written about the interface at the ends of a backplane
where the bus extenders hook to the A and B slots.  Plug-
in cards all used the C D E and F slots.  This pinout was
a (sort-of) secret.  If you look at the documentation
for Unibus, you can't actually figure out how the IRQ's
are daisy-chained when there's only one pin assigned for each.
That's of course only on the A B slots.  Qbus is a better
documented bus.

IIRC Qbus had 4 or five of these interrupt chains, one for each
available interrupt priority level.  So the CPU still had to
deal with the interrupt priority.  Also I believe there were
many more soft interrupt levels on those CPU's.  Probably
not very interesting for a small compact CPU as mentioned
in the OP.  My original comments were based on my limited
memory of 8085 and 6800 which I worked with in the early
days of my career, before VHDL when design was pencil on
vellum....

-- 
Gabor

Article: 156137
Subject: Re: Implementing multiple interrupts
From: "Andy (Super) Glew" <andy@SPAM.comp-arch.net>
Date: Sun, 08 Dec 2013 11:00:35 -0800
Links: << >>  << T >>  << A >>
On 12/7/2013 4:04 AM, Aleksandar Kuktin wrote:
> Hi all.
>
> Some time ago, I designed a small and simple CPU to go into a project I
> am sort-of working on (when can I steal the time to do so). Now, I added
> an interrupt mechanism to it and encountered a problem when I tried to
> turn the one-interrupt interrupt into a multiple-interrupt interrupt -
> the kind all other CPUs have these days.
>
> Here's my gripe: suppose the CPU enters interrupt 1. While it is
> interrupted, IRQ2 comes in. And then IRQ3 comes in, followed by IRQ4. WTF
> am I supposed to do now? I want all IRQ-s to be handled. So, no ignoring.
>
> My first idea was to make a stack and push the interrupt contexts onto
> the stack as new IRQs come in and pop them as the software interrupt
> handlers return. But this is far too elaborate to be implemented in
> reasonably little resources.
>
> My second idea was to have every IRQ assert a bit in a special reqister
> before asserting the unified IRQ signal. Then I would mandate that the
> software interrupt handler iterates over the register and handles IRQs
> that it finds asserted. And when it is done, the interrupt handler would
> reiterate over the register to catch any interrupts that came in during
> the handling of the previous ones. I currently plan to use a variant of
> this method.
>
> While writing this I also came up with the option of deffering IRQs until
> the previous one's handling returns. Probably with some sort of a stack.
> If done correctly, it should take little resources.
>
> What to other CPUs usualy do in these situations?

Fun stuff, eh?  I keep thinking that interrupt architecture is one of 
the areas of computer architecture that is most in need of cleanup. I 
want to do a writeup, a survey, for my comp-arch.net wiki -- 
understanding the state of the art is what I usually do before trying to 
advance it.

Anyway  - what do other CPUs do?

Most CPUs allow interrupt preemption.  They save the state of the 
preempted thread / interrupt handler somewhere.  Where they save the 
state varies. I'll summarize that later, but this thread inspires me to 
start from the simplest thing.

---+ Interrupt Source

In the beginning there was an interrupt pin...  (oooo, this will be a 
cool slideset. complementary to my tutorial on memory, which begins 
"This is a bit..." with a big dot in the middle of the page, which is 
still my favorite.)

Inevitably, people wanted multiple interrupt sources, multiple interrupt 
pins.   Sometimes they treated them uniformly: INT0, INT1, INT2 ... . 
Sometimes they created different mechanisms for different pins: INT, 
NMI, SMI, FERR, MCERR ...  Fundamentally, even if different mechanisms, 
the same issues arise - often it is as if each interrupt source takes a 
different combination of the options we are about the list.

But let's deal with interrupt sources.  Pins, easy to understand.  Level 
triggered.  Edge triggered => edge detector. Detect on risi9ng edge, 
falling edge, both. Glitches - level triggered interrupt pins that rise 
and then fall too quickly to actually trigger and interrupt. Similarly 
for edge triggered.

Non-pin interrupt sources: ECC on memory.  Internal exceptions, not from 
outside world: cache or register parity.

Interrupt delivery mechanisms: interrupt controller outside in the 
system, that delivers and routes interrupts to various targets.  E.g. 
different CPUs.  Dedicated interrupt farics / busses, like the original 
Intel MPIC serial bus.

More non-pin: bus messages on the memory bus, like Intel XAPIC.  Makes 
it easier to reason about ordering of interrupts and memory requests. 
Makes "level triggered" less meaningful, edge triggered more natural:
level triggered requires messages to be sent on both high-to-low and 
low-to-high transitions.  Edge triggered only requires one message.

I still think that interrupt "pins" are the fundamental primitive, and 
will be so long as we are working with wires.  Even when you have bus 
message based interrupts, inevitably the messages are received by logic 
at the target, and then assert signals - the good old INT, NMI, etc, - 
into the CPU core or cores.

---+ Detecting interrupts

Pre-beginning: polling.   Read the pin, possibly compare it to a 
previous value.  Decide what to do.

Interrupts really begin when software doesn't have to poll.  Dedicated 
logic does.  And dedicated logic then tries to get software to do something.

---+ Interrupt delivery

OK, so what do you do when you detect an interrupt?

Pre-beginning:   unconditionally force the PC to specific value. 
Throwing away whatever the old PC was.

This is limited, so we start thinking about saving the PC at point of 
interrupt somewhere.

0) dedicated save register

    Interrupted_PC := PC
    PC := interrupt_handler_PC

1) switch PC

         current_PC
         non_interrupt_PC
         interrupt_handler_active_PC,
         interrupt_handler_start_PC (constant)

    on new interrupt:
	interrupt_handler_active_PC := interrupt_handler_start_PC
                  (may be preloaded)
         current_PC = interrupt_handler_active_PC (points to)

    on interrupt return
         current_PC = non_interrupt_PC

Note: fundamentally delivering an interrupt is an edge triggered action.

I think dedicated "save register" and "switch PC" are isomorphic, dual.
Although the details matter.  I will try to say "save/switch" interrupt 
state.

Many systems have a mix: some interrupt sources switch, others save.

Oftentimes, switching is suggested as the solution to all of the 
problems that saving has. Or vice versa.  So we end up with inconsistent 
interrupt handling mechanisms. :-(

Either can be scaled to apply to multiple interrupt sources and 
save/switch PCs.

Nearly all systems save/switch not just PC, but also some other 
registers. Typically some register that can be used in addressing 
memory.  Often this is called a "interrupt handler stack pointer", but 
it doesn't have to be a stack.

Execution mode / privilege (although not applicable to simplest systems 
that do not have privilege).

More:

2) Save/switch sets of registers.

3) Save/switch registers to blocks of memory.   Basically, to avoid 
having to build lots of hardware registers.

E.g. Gould SEL machines had one of the most elegant save/switch 
mechanisms I have encountered.  Perhaps not so much elegant, but very 
simple, instructive.   Each of the many interrupt "vectors" had a memory 
block. Interrupt delivery consisted of saving (a subset of) current 
register state in the  memory block, and loading new register state from 
a different part of the memory block.  Delivery of new interrupts using 
that same memory block was prevented, until software had moved the state 
somewhere else, out of the memory block, at which point that interrupt 
source was unblocked

By the way: note "save old state / load new state".   Basically a state 
exchange.   CDC "exchange jump".  Could be same memory, although IMHO 
that complicates state management.

Typically the old state save area is coupled with, related to, the 
interrupt vector, and the area from which new state for the interrupt 
handler is loaded.   But it doesn't have to be this way.  In some 
systems, you want the saved state of the interrupted thread/process to 
be protected from the interrupt handler - i.e. you do not necessarily 
assume that the interrupt handler is higher privilege that what got 
interrupted.   The interrupt handler often does not need to know what 
got interrupted. Think - I/O interrupts.  But many other uses need 
handler to know what got interrupted - think timer interrupts for 
profiling, OS context switching.   Anyway, what I am trying to say is 
that some sort of linkage to what got interrupted needs to be saved, but 
not necessarily directly accessible.

Some systems with "Processor Control Blocks" or "Processor State Blocks" 
in memory save the interrupt state into that.
But if every interrupt saves into the same PSB, then you cannot nest 
until that state has been moved somewhere else - unless the PSB itself 
is changed as a result of each interrupt.

Basically, the save area is something chosen from the cross product of
Privilege_Domains X Interrupt_Sources.

(Of course, can always emulate complicated interrupt architectures like 
this on top of simpler architectures - like assuming interrupt handler 
is more privileged.  And then let the privileged SW int handler switch 
to a less privileged actual interrupt handler.   Similarly, we often say 
"interrupt return", as in "return to that which got interrupted, and 
resume".  In reality, it is "end of interrupt handler", and then a 
scheduling mechanism (HW or SW) picks up whatever is most appropriate. 
Possibly return to that which got interrupted.  But possibly switch.)

4) Save/switch onto stacks

It is quite common to push interrupts onto a stack - possibly THE stack. 
Avoids need for so many dedicated save areas.   Typically, SW then moves 
stuff off the stack, ...

But once you start doing this, you quickly realize that you want 
multiple stacks.  E.g. separate user / kernel stacks, separate by 
privilege.   Which typically involves switching or saving registers, to 
change the stack pointer used, and then the memory accesses.

Basically, we can see that you have a dedicated stack per privilege 
domain (thread/process/user/supervisor).  Nested interrupts / higher 
priority interrupts that run in the same privilege domain may be able to 
save on the same stack, pushing, incrementing stack pointer.  Avoids the 
need for need to allocate per interrupt source, i.e. to have the full 
cross product of Privilege_Domains X Interrupt_Sources.

GLEW OPINION / BKM:
0)save/switching register state for simplest systems.
1) If things get more complicated, save/switch to memory
1.1) Old/new state per interrupt source
1.2) Or: save old state to PSB, load new state, including PC and PSB
      Leaving TBD the issue of where to link the saved PSB.


Although switching stacks is common, IMHO it is complicated.  For a 
simple implementation, I suggest one of the above. Save/switch through 
registers or memory.

---++ How much state to save?

Lots of brainpower has been spent on minimizing the amount of state to 
be loaded / saved / switched/

Obviously, must save/switch PC.   Typically privilege.  And usually a 
register used in memory addressing - stack pointer, or PSB.

You can leave other state in registers to be saved/restored by software, 
right?

Well...

a) Yes if int handler privileged...  big issues if not

b) Yes if int handler knows about and how to save state.

Problems arise with long lived computer architectures that have legacy 
concerns.   E.g. an int handler that knows about 32-bit GPRs, but 
doesn't know about 64-bit GPRs.  Or an int handler than knows about 128 
bit XMM registers, but not about 256 or 512 bit YMM registers.  Where 
accessing a 128-bit register zeroes out the upper bits if 512-bit registers.

If you assume that OS software in an interrupt handler knows about the 
state.   But, oftentimes the reason we are doing virtual machines is to 
keep legacy OSes running.

These concerns are often coupled, related, to overlapped versus 
non-overlapped, partial registers, etc.  I.e. if you want the simpler 
for hardware approach of zero or sign extending small register writes to 
full register width, to avoid partial register issues, you may be 
required that your privileged resource architecture save more registers, 
either in hardware or software.

Or, you can simplify interrupts by supporting partial register writes.

Or...  various flavors of lazy save/restore (after an interrupt, trap if 
tricky registers are accessed.  But then the trap handler just needs to 
know what to do about the state.  There have been examples where lazy 
save/restore was not kept consistent with OS policies, producing 
security holes.)

Or... state saving instructions like Intel XSAVE.

---++ Threads

I can't quite work this into my taxonomy, so let me just say: one of the 
most common unusual or alternative interrupt schemes is thread based. 
Instead of logically switching threads, you start off with a 
multithreaded processor, and interrupt delivery conceptually just 
unblocks a stalled thread, the thread for the interrupt handler. 
Conceptuially letting the interruopted thread continue execution.

Elegant...

If the threads are loaded into registers, scaling issues.  But a nice 
approach for a dedicated system.

If the thread state is in memory - but then hardware is doing CPU 
scheduling function.  I like it, but that's a whole other topic.

Issue: what about profiling interrupts, where the interrupt handler 
wants to inspect the thread that was interrupted.

Dedicating CPUs to interrupts - same thing.  Same elegance, same 
scalability.

Up to the point where hardware is free, we will always have scaling 
issues.  The issues of how to switch state will always be there - but 
techniques like saving/switching register sets, or activating interrupt 
handler threads or CPUs, put the issue off.  Possibly off far enough 
that it can be deferred to software, and hardware doesn't have to worry.

But there will always be the need for an interrupt handler thread / CPU 
to preempt or access state another thread/CPU.  That will always need a 
hardware mechanism - inter-thread or inter-processor interrupts.  It 
just can be reduced in frequency.

And, I think on general purpose CPUs, we will probably need to multiplex 
multiple threads/processes for 10-20 years more.  I suspect forever.

I.e. dedicated interrupt handling threads/CPUs are something for the 
toolbox.  But are not general purpose. Not universal.

---+ Blocking or Masking interrupts

Must always be able to block interrupts, even with a single pin. 
Basically a bit that says "interrupt handler in progress, can't 
save/switch state".   Inevitably extended to also be used to block 
interrupts when interrupt handler not in progress,

Blocking bit.

Multiple: blocking bitmask.  Or, level - accepting ints of higher priority.

GLEW: I like bitmasks.  One bit per save area.
     Levels are more compact.  Allows you to have many morte save areas 
in memory, without excessive bitmask storage.
     Levels can tie you up in knots - because actually interrupt 
handlers change their priority during their lifetime.
     Bitmasks, though, add to state that must be saved / restored.

Basically, mixing up, entwining, two concepts:
    a) interrupts that must be blocked because the save area for them is 
in use.  (Statically save/switched, regs or memory; not so much 
dynamically allocated, stacks.)
    b) interrupts that must be blocked because of simplistic mutual 
exclusion policies.

I suppose could have both.

Levels are always simplistic for mutual exclusion. Level/bitmask?

---++ What about NMIs?

What about NMIs? Non-Maskable Interrupts.

GLEW OBSERVATION:
a) first you add ordinary interrupts
b) then you add NMIs. NMIs are supposed to never return.
c) but then you want to have NMIs that return...
    e.g. profiling all code.
    e.g. hypervisor wants to context switch an OS that uses NMIs
    NOTE: must then guarantee that NMI state doesn't collide with 
ordinary ints

d) ... eventually, it seems that most mature architectures in fact have 
a mask bit for non-maskable interrupts.  A mask bit separate from the 
mask bit for ordinary interrupts.

---++ Masking interrupts at start of handler

Simplicity can supposedly be obtained by masking state at the start of 
an interrupt handler - to give the OS a chance to save state, before 
allowing others.

Can be automatic - 1 or N-instruction window.

Or int handler may be trusted.

But...  when you start virtualizing, or when you have NMIs that you want 
to guarantee do not get masked.

I.e. automatic masking is an optimization. Does not work in general, but 
in specific cases.


---+ Queuing interrupts

With a single pin, level triggered, there isn't really much of a queue.

1 bit, interrupt pending.
Another bit, interrupt active.

Issues wrt clearing the bits as returning.   Nearly always a special 
interrupt return instruction.  (x86 special "deferred" handlimng of 
instruction after CLI/STI.)

With multiple interrupt sources, a bitmask.

Multiple arrivals sharing same bitmask -
0) don't do that (simplistic)
1) saturate - OR into existing.

Structure often seen: 1 deep satuirating queue (per bitmask position).

1 bitmask, but per int group, for "this interrupt is dispatched, handker 
has been started" (although may have been preempted).

Second bitmask for pending interrupt that has not yet been dispatched.

Less often: 2-deep saturating queue.  x86 APIC?  (Why...  circuits.)

Much less common: deeper queues, less combining. Some event driven 
RTOSes simplified by keeping interrupt requests separate, unmerged. 
Inevitably must handle possibility of interrupt overflow.  But this can 
become an error condition, rather than common.

Issue:

Conceivable, but I am not aware of: counter per interrupt group./  I 
think it has worst properties: still need to poll if multiplexed int 
sources.


---+ Conclusion

Lots of combinations of these mechanisms.

I think I am stopping because of exhaustion of myself, not of the 
possibilities seen, that I want to document.

-- 
The content of this message is my personal opinion only. Although I am 
an employee (currently Imagination Technologies, which acquired MIPS; in 
the past of companies such as Intellectual Ventures/QIPS, Intel, AMD, 
Motorola, and Gould), I reveal this only so that the reader may account 
for any possible bias I may have towards my employers' products. The 
statements I make here in no way represent my employers' positions on 
the issue, nor am I authorized to speak on behalf of my employers, past 
or present.

Article: 156138
Subject: Re: Implementing multiple interrupts
From: Ivan Godard <ivan@ootbcomp.com>
Date: Sun, 08 Dec 2013 11:53:15 -0800
Links: << >>  << T >>  << A >>
On 12/8/2013 11:00 AM, Andy (Super) Glew wrote:
<snip>


 > Fun stuff, eh?  I keep thinking that interrupt architecture is one of
 > the areas of computer architecture that is most in need of cleanup.

<snip of Andy being amazing :-) >

> Lots of combinations of these mechanisms.
>
> I think I am stopping because of exhaustion of myself, not of the
> possibilities seen, that I want to document.
>

What a mess. We decided early on that we didn't want to deal with it.

A distinction that was useful to us: a fault, a trap, and an interrupt 
are not the same thing.

* A fault is internally generated by the running program, and has 
termination semantics. Example: illegalInstruction

* A trap is internally generated, not necessarily associated with a 
particular program or execution, and has resumption semantics. Example: 
not-present-page trap.

* An interrupt is externally generated and has resumption semantics. 
Example: i/o complete interrupt.

The difference between interrupt and trap boils down to whether the 
event can be precluded by having the CPU avoid doing anything that would 
raise it (a trap), or whether the event is triggered by something that 
is outside CPU control (interrupt).

For all three, handler invocation is an involuntary function call, and 
the handler is a function like any other. All three have dispatch 
vectors that are simply arrays of function pointers indexed by event 
kind; the vectors are in memory and the three vector roots are in 
hardware registers. Hardware detecting an event selects the appropriate 
root, indexes the vector with the event kind, and calls the function.

The expected use is that the fault vector and its root are in the 
executing turf and hence under the control of the faulting program (or 
more likely its run-time system). Trap and interrupt vectors are not 
expected to be in the application turf but instead in a turf used by the 
OS for event management. Trap and interrupt handlers are expected to be 
distant functions (the invocation switches turf); fault handlers may or 
may not be.

Cascaded faults (including an attempt to return from a fault handler) 
causes a trap. The trap handler clears up the rubble.

Article: 156139
Subject: Re: Implementing multiple interrupts
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Sun, 8 Dec 2013 20:23:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Sun, 08 Dec 2013 11:00:35 -0800, Andy (Super) Glew wrote:

> [snip]
> 
> ---++ Threads
> 
> I can't quite work this into my taxonomy, so let me just say: one of the
> most common unusual or alternative interrupt schemes is thread based.
> Instead of logically switching threads, you start off with a
> multithreaded processor, and interrupt delivery conceptually just
> unblocks a stalled thread, the thread for the interrupt handler.
> Conceptuially letting the interruopted thread continue execution.

I *really* like this idea.

> [snip]
> 
> ---+ Queuing interrupts
> 
> [...]
> 
> Much less common: deeper queues, less combining. Some event driven
> RTOSes simplified by keeping interrupt requests separate, unmerged.
> Inevitably must handle possibility of interrupt overflow.  But this can
> become an error condition, rather than common.

I think I will implement a variant of queuing. Or, as I have begun to 
call it, "deffering". After posting the original post yesterday, I gave 
the idea thought and figured out I can make a sufficiently small 
mechanism that does this.

Originally I was going to use a stack but stack is a FILO construct and I 
need a FIFO so I'll probably use a ring buffer with two pointers (read 
and write) pointing into it. So an interrupt request makes the IRQ buffer 
unit write into the appropriate place that the IRQ has been received as 
well as which IRQ was it. Actually, it will just write and increment the 
write pointer. Logic can figure out the interrupt is pending because 
there is a used memory slot between the read and write pointers. Then, if 
the CPU is not in interrupt, it gets interrupted. If it is in interrupt, 
nothing happens untill the interrupt handler returns when the CPU 
immediatelly gets pushed back into an interrupt.

With a sufficiently big ring buffer, sufficiently fast interrupt handlers 
and sufficiently interspersed interrupt requests, this scheme should 
handle all of my needs for the concievable future.

> [...]

Article: 156140
Subject: Re: Implementing multiple interrupts
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Sun, 8 Dec 2013 20:29:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Sat, 07 Dec 2013 20:26:26 +0000, Tom Gardner wrote:

> On 07/12/13 12:04, Aleksandar Kuktin wrote:
>> [snip]
> 
> Consider "level triggered" interrupts rather than edge triggered
> interrupts...
> 
> Every peripheral (etc) generates an interrupt which pulls a single
> signal high until that interrupt has been cleared by the relevant
> interrupt service routine (ISR) and the return from interrupt (RTI)
> instruction executed.
> 
> If a second interrupt arrives before the first one has been cleared,
> then it too pulls the same signal high - which has zero effect. When the
> ISR has cleared the first interrupt and the RTI executed, the processor
> immediately enters the ISR for the second interrupt.

Interesting concept. Suppose I'll check out Z80 and the Motorola. Always 
had a suspicion I'll end up doing something with Z80.

> Hence all the interrupts are dealt with serially without preemption. If
> you want preemption then you have to design a hierarchy of interrupts
> and be prepared to stack one context for each level in the hierarchy.
> Many processors manage with two levels, typically a maskable interrupt
> and a non-maskable interrupt.
> 
> Have a look at early microprocessors, e.g. the Z80 or 6800.

Article: 156141
Subject: Re: Implementing multiple interrupts
From: Jecel <jecel@merlintec.com>
Date: Mon, 9 Dec 2013 06:25:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, December 8, 2013 6:23:26 PM UTC-2, Aleksandar Kuktin wrote:
> On Sun, 08 Dec 2013 11:00:35 -0800, Andy (Super) Glew wrote:
> > [snip]
> > ---++ Threads
> > I can't quite work this into my taxonomy, so let me just say: one of th=
e
> > most common unusual or alternative interrupt schemes is thread based.
> > Instead of logically switching threads, you start off with a
> > multithreaded processor, and interrupt delivery conceptually just
> > unblocks a stalled thread, the thread for the interrupt handler.
> > Conceptuially letting the interruopted thread continue execution.
>=20
> I *really* like this idea.

One advantage of using co-routines instead of subroutines for handling inte=
rrupts is that the suspended PC encodes some state while since the subrouti=
ne (traditional) interrupt handler always starts at the exact same address =
it has to spend some time figuring out the current system state.

The TX-2 machine (MIT Lincoln Laboratory) was an early co-routine based des=
ign and the Xerox PARC machines starting with the Alto used this extensivel=
y. I have used this in some of my designs (using the distributed RAM instea=
d of the flip-flops in FPGA slices for register allows you to have, for exa=
mple, 16 PCs in the same area you would normally just have one) and it can =
work very well.

At the software level, the Apertos (later Aperios) operating system from So=
ny Labs implemented its drivers as co-routines instead of subroutines.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.55.5315

-- Jecel

Article: 156142
Subject: How to feed the simulated VHDL implemented synthesizer with MIDI
From: Wojciech M. Zabolotny <wzab@ise.pw.edu.pl>
Date: Mon, 9 Dec 2013 18:33:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi,

One of my students is working on musical sound synthesis in FPGA.
To allow her to test her solution before the design is ready
to be programmed into real FPGA, I needed a solution translating
the MIDI file into the stream of MIDI commands which may be read
by the VHDL simulator.
Unfortunately I was not able to find such a converter ready to use,
and therefore I have implemented it myself.
I hope that this solution may be useful for others, working with
similar problems (and probably may be fixed/improved by others),
therefore I have decided to submit it to this group.

Due to some VHDL limitations, the provided toolset first converts
the MIDI file to the text file, containing lines with the absolute 
time, when the particular MIDI command is set, and then bytes
belonging to that command.
This text file is then interpreted by the provided read_midi entity,
which produces the read MIDI commands to the connected synthesizer
IP core, at the appropriate simulation time.
The output interface of the read_midi entity uses a simple asynchronous
handshake system, which allows to easily interface it with the synthesizer.

The Python part of the solution is heavily based on the wonderful
Python MIDI library written by Giles Hall, and available at:
https://github.com/vishnubob/python-midi

My sources, together with the description are available on:
https://github.com/wzab/python-midi-2-vhdl/tree/master/midi2vhdl
Additionally the sources are published on alt.sources group
(subject: Tools for feeding the simulated VHDL implemented 
music synthesizer with data from MIDI file
google archive: https://groups.google.com/forum/#!topic/alt.sources/aVdyFtsho_I )

Please note, that the described solution is for simulation
only!
-- 
Regards,
Wojciech M. Zabolotny
wzab@ise.pw.edu.pl

My GPG/PGP keys:
standard: B191 ACF0 7909 83FA 3F9B  450C 407E 3C4B 4569 D119
confidential: 2BF3 F90F 6EA8 7D35 59FD  5080 78ED 33DE 1312 D8F8



Article: 156143
Subject: BUFG Issue on Virtex 5 FPGA
From: Venkat <venkat.japan@gmail.com>
Date: Tue, 10 Dec 2013 03:01:49 -0800 (PST)
Links: << >>  << T >>  << A >>
Folks,

I observe a curious problem on my FPGA Build on Virtex 5 FPGA and would lik=
e to understand if any of you had seen this before.

As part of SoC Emulation, I have coded my FPGA RTL with a bunch of Clock Bu=
ffers (in order to emulate Clock Gating on internal logic) which was consum=
ing about 10 Buffers. This design build was working on the platform as expe=
cted and I wanted to free-up the BUFGs for other usage and hence eliminated=
 the initial bunch of them by commenting them out replacing them with direc=
t assign statements with no clock enable. Though the Build result reflected=
 reduction in the BUFG count, I saw that the FPGA Logic is continuously hel=
d on POR and is not getting released for operations. I use the clock direct=
ly from the IO and do not use any DCM/PLL. I have used one BUFG for the Asy=
nchronous Reset from the IO which is ANDed with another IO signal.

Did someone else come across this kind of observation?

Appreciate everyone's response.

regards,
Venkat.

Article: 156144
Subject: Re: Interface Xilinx KC705 to BeagleBone?
From: pfraser <pete_fraser@comcast.net>
Date: Tue, 10 Dec 2013 08:43:15 -0800
Links: << >>  << T >>  << A >>
david.middleton@gmail.com wrote:
> Hi Pete,
>
> We are just prototyping a similar board to talk to a AD9361.
>
> Are you progressing with the plan to interface through the GPMC, and if so what are your software resources?
>
> We are currently developing drivers with the intention of releasing a vhdl opencore & gpmc device driver but at this stage we are as vapour as everyone else (which is to say we are a reasonable way from being manufacturable).
>

I got sidetracked, so haven't had much of a chance to look
at this yet. I'm a hardware guy, so I'd just be making
up the software is I go along. I'd certainly be interested
in the stuff that you're doing when I get back to this.

It looks like the BeagleBone Black is a nice choice,
but there's contention for a couple of GPMC balls, so
the board would need to boot off the SD card (on-board
flash disabled in device tree).

Are you using the black, or the white?

Pete


Article: 156145
Subject: Re: MachXO breakout board as a programmer
From: jg <j.m.granville@gmail.com>
Date: Thu, 12 Dec 2013 20:35:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, December 7, 2013 10:51:28 PM UTC+13, Gergo wrote:
> Hi!
> I'd like to use my MachXO Breakout Board as a programming device to program a custom MachXO chip on a board. Is that possible at all? I could not find anything useful in the board's user guide. Any tip would be highly appreciated!

Yes, I've used a XO2 breakout board to pgm other vendor parts.

As Gabor mentioned, get to the Schematic and find the components or possibly headers, and see what is needed to isolate the on-chip JTAG, and bring the link-jtag off the board.
 In my case, I think I cut two traces, and lifted 2 SMD resistors. 
-jg

Article: 156146
Subject: New Cloud Based VHDL Simulator-Tarang
From: neer4j.iit.delhi@gmail.com
Date: Thu, 19 Dec 2013 02:05:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Tarang EDA has launched Cloud based VHDL functional verification tool to quickly with many new features which are not possible in Desktop/Offline Tools.

No Bulky Installations
Fastest Simulation
Work as Teams
Work from anywhere
Platform Independent

You can try it on http://www.tarangeda.com

Article: 156147
Subject: Re: New Cloud Based VHDL Simulator-Tarang
From: HT-Lab <hans64@htminuslab.com>
Date: Thu, 19 Dec 2013 10:27:32 +0000
Links: << >>  << T >>  << A >>
On 19/12/2013 10:05, neer4j.iit.delhi@gmail.com wrote:
> Tarang EDA has launched Cloud based VHDL functional verification tool to quickly with many new features which are not possible in Desktop/Offline Tools.
>
> No Bulky Installations
> Fastest Simulation
> Work as Teams
> Work from anywhere
> Platform Independent
>
> You can try it on http://www.tarangeda.com
>

We collect following information:
1.Information provided by you during registration
2.Cookies
3.Your content and project files
4.Your IP address in various log files
5.Geo-Location Information
6.Device Identifiers

ough...... you might want to change this if you want to target any 
(serious) developers.

Hans
www.ht-lab.com


Article: 156148
Subject: ppc405 communication with custom ip ml403
From: khan990@gmail.com
Date: Thu, 19 Dec 2013 07:20:18 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Everyone!
I am trying to simulate a chemical reaction in FPGA.
=20
My basic FPGA architecure consists of 3 processes:
=20
-- Synchronous Process
--Purely Synchronous with asynchronous SET or RESET
IGNITE : PROCESS(clk, reset)
begin
IF( reset =3D '1' ) THEN --Synchronous Reset
Current_State <=3D ASSIGN_VARS;=20
ELSIF (clk'event AND clk =3D '1') THEN --Rising edge of Clock
Current_State <=3D Next_State;
END IF;
END PROCESS IGNITE;
=20
=20
CIRCUIT : PROCESS(Current_State,
-- And all other sensitivity list signals
) -- include the one read.
BEGIN
CASE Current_State IS
        WHEN ASSIGN_VARS =3D>
                   -- LONG 3000 lines of code here
                   -- see the attached file
END CASE;
END PROCESS CIRCUIT;
=20
--Purely Synchronous with asynchronous SET or RESET
INITIALIZE : PROCESS(clk, reset)
BEGIN
IF(reset =3D '1') THEN
glucose_reg <=3D zeros27;
ATP_reg <=3D zeros27;
glucose_6_phosphate_reg <=3D zeros27;
ADP_reg <=3D zeros27;
fructose_6_phosphate_reg <=3D zeros27;
fructose_1_6_bisphosphate_reg <=3D zeros27;
dihydroxyacetone_phosphate_reg <=3D zeros27;
glyceraldehyde_3_phosphate_reg <=3D zeros27;
bisphosphoglycerate_1_3_reg <=3D zeros27;
phosphoglycerate_3_reg <=3D zeros27;
phosphoglycerate_2_reg <=3D zeros27;
phosphoenolpyruvate_reg <=3D zeros27;
pyruvate_reg <=3D zeros27;
Pi_reg <=3D zeros27;
H2O_reg <=3D zeros27;
NAD_reg <=3D zeros27;
NADH_reg <=3D zeros27;
H_reg <=3D zeros27;=20
--BRAM=20
ADDRESS_A_reg <=3D zeros10;
DATA_IN_reg <=3D zeros27;
--
SAVE_DATA_reg <=3D zeros10;
TEMP_reg <=3D zeros5;
IN_REACTIONS_reg <=3D B"0";
TEMP_STATE_reg <=3D ASSIGN_VARS;
ELSIF(clk'event AND clk =3D '1') THEN
glucose_reg <=3D glucose_sig;
ATP_reg <=3D ATP_sig;
glucose_6_phosphate_reg <=3D glucose_6_phosphate_sig;
ADP_reg <=3D ADP_sig;
fructose_6_phosphate_reg <=3D fructose_6_phosphate_sig;
fructose_1_6_bisphosphate_reg <=3D fructose_1_6_bisphosphate_sig;
dihydroxyacetone_phosphate_reg <=3D dihydroxyacetone_phosphate_sig;
glyceraldehyde_3_phosphate_reg <=3D glyceraldehyde_3_phosphate_sig;
bisphosphoglycerate_1_3_reg <=3D bisphosphoglycerate_1_3_sig;
phosphoglycerate_3_reg <=3D phosphoglycerate_3_sig;
phosphoglycerate_2_reg <=3D phosphoglycerate_2_sig;
phosphoenolpyruvate_reg <=3D phosphoenolpyruvate_sig;
pyruvate_reg <=3D pyruvate_sig;
Pi_reg <=3D Pi_sig;
H2O_reg <=3D H2O_sig;
NAD_reg <=3D NAD_sig;
NADH_reg <=3D NADH_sig;
H_reg <=3D H_sig;=20
--BRAM=20
ADDRESS_A_reg <=3D ADDRESS_A_sig;
DATA_IN_reg <=3D DATA_IN_sig;
--
SAVE_DATA_reg <=3D SAVE_DATA;
TEMP_reg <=3D TEMP_sig;
TEMP_STATE_reg <=3D TEMP_STATE_sig;
IN_REACTIONS_reg <=3D IN_REACTIONS_sig;
END IF;
END PROCESS INITIALIZE;
=20
I can communicate with this IP from PPC but in a very strange way.=20
=20
#include "xmk.h"
#include "sys/init.h"
#include "platform.h"
#include <stdio.h>
#include <string.h>
#include "platform.h"
#include "xparameters.h"
#include "xbasic_types.h"
#include "xstatus.h"
#include "xgpio.h"
#include "source.h"
#include <sys/timer.h>
#include "checkppc6.h"

#include <stdio.h>
Xuint32 *baseaddr_p =3D (Xuint32 *)XPAR_CHECKPPC6_0_BASEADDR;
int main()
{
init_platform();
XASSERT_NONVOID(baseaddr_p !=3D XNULL);
baseaddr =3D (Xuint32)baseaddr_p;
CHECKPPC6_mReset(baseaddr);
CHECKPPC6_mResetReadFIFO(baseaddr);
CHECKPPC6_mResetWriteFIFO(baseaddr);
=20
CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // activate signal
=20
DataFPGA =3D CHECKPPC6_mReadFromFIFO(baseaddr, 0);
=20
}
=20
I donot see the initial value from FPGA IP until I send an empty useless va=
lue to IP input (which is CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); =
// activate signal). In my view a simple software reset (CHECKPPC6_mReset) =
should have initialized the IP and given me the output value I assign in AS=
SIGN_VARS case of my IP.
=20
My IP design is such that. IP asks the input of chemical molecules. then pe=
rform reaction and wait for ACK signal from PPC to continue with the next r=
ound.
=20
But the problems I face are. I have to (CHECKPPC6_mWriteToFIFO(baseaddr, 0,=
 0xffffffff); // activate signal) for no intuitive reason. Then when I prov=
ide ACK signal, IP doesnt move on to start Reaction again untill I provide =
another dummy input (CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // ac=
tivate signal).
=20
I believe next_state doesnot get updated, which is why it happens, can you =
guys please help me with this and suggest a solution.
=20
please see attached files for more info.

Article: 156149
Subject: PPC 405 communication with custom IP ml403
From: Jasim Khan <khan990@gmail.com>
Date: Thu, 19 Dec 2013 12:03:37 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Everyone!
I am trying to simulate a chemical reaction in FPGA.
=20
My basic FPGA architecure consists of 3 processes:
=20
-- Synchronous Process
--Purely Synchronous with asynchronous SET or RESET
IGNITE : PROCESS(clk, reset)
begin
IF( reset =3D '1' ) THEN --Synchronous Reset
Current_State <=3D ASSIGN_VARS;=20
ELSIF (clk'event AND clk =3D '1') THEN --Rising edge of Clock
Current_State <=3D Next_State;
END IF;
END PROCESS IGNITE;
=20
=20
CIRCUIT : PROCESS(Current_State,
-- And all other sensitivity list signals
) -- include the one read.
BEGIN
CASE Current_State IS
        WHEN ASSIGN_VARS =3D>
                   -- LONG 3000 lines of code here
                   -- see the attached file
END CASE;
END PROCESS CIRCUIT;
=20
--Purely Synchronous with asynchronous SET or RESET
INITIALIZE : PROCESS(clk, reset)
BEGIN
IF(reset =3D '1') THEN
glucose_reg <=3D zeros27;
ATP_reg <=3D zeros27;
glucose_6_phosphate_reg <=3D zeros27;
ADP_reg <=3D zeros27;
fructose_6_phosphate_reg <=3D zeros27;
fructose_1_6_bisphosphate_reg <=3D zeros27;
dihydroxyacetone_phosphate_reg <=3D zeros27;
glyceraldehyde_3_phosphate_reg <=3D zeros27;
bisphosphoglycerate_1_3_reg <=3D zeros27;
phosphoglycerate_3_reg <=3D zeros27;
phosphoglycerate_2_reg <=3D zeros27;
phosphoenolpyruvate_reg <=3D zeros27;
pyruvate_reg <=3D zeros27;
Pi_reg <=3D zeros27;
H2O_reg <=3D zeros27;
NAD_reg <=3D zeros27;
NADH_reg <=3D zeros27;
H_reg <=3D zeros27;=20
--BRAM=20
ADDRESS_A_reg <=3D zeros10;
DATA_IN_reg <=3D zeros27;
--
SAVE_DATA_reg <=3D zeros10;
TEMP_reg <=3D zeros5;
IN_REACTIONS_reg <=3D B"0";
TEMP_STATE_reg <=3D ASSIGN_VARS;
ELSIF(clk'event AND clk =3D '1') THEN
glucose_reg <=3D glucose_sig;
ATP_reg <=3D ATP_sig;
glucose_6_phosphate_reg <=3D glucose_6_phosphate_sig;
ADP_reg <=3D ADP_sig;
fructose_6_phosphate_reg <=3D fructose_6_phosphate_sig;
fructose_1_6_bisphosphate_reg <=3D fructose_1_6_bisphosphate_sig;
dihydroxyacetone_phosphate_reg <=3D dihydroxyacetone_phosphate_sig;
glyceraldehyde_3_phosphate_reg <=3D glyceraldehyde_3_phosphate_sig;
bisphosphoglycerate_1_3_reg <=3D bisphosphoglycerate_1_3_sig;
phosphoglycerate_3_reg <=3D phosphoglycerate_3_sig;
phosphoglycerate_2_reg <=3D phosphoglycerate_2_sig;
phosphoenolpyruvate_reg <=3D phosphoenolpyruvate_sig;
pyruvate_reg <=3D pyruvate_sig;
Pi_reg <=3D Pi_sig;
H2O_reg <=3D H2O_sig;
NAD_reg <=3D NAD_sig;
NADH_reg <=3D NADH_sig;
H_reg <=3D H_sig;=20
--BRAM=20
ADDRESS_A_reg <=3D ADDRESS_A_sig;
DATA_IN_reg <=3D DATA_IN_sig;
--
SAVE_DATA_reg <=3D SAVE_DATA;
TEMP_reg <=3D TEMP_sig;
TEMP_STATE_reg <=3D TEMP_STATE_sig;
IN_REACTIONS_reg <=3D IN_REACTIONS_sig;
END IF;
END PROCESS INITIALIZE;
=20
I can communicate with this IP from PPC but in a very strange way.=20
=20
#include "xmk.h"
#include "sys/init.h"
#include "platform.h"
#include <stdio.h>
#include <string.h>
#include "platform.h"
#include "xparameters.h"
#include "xbasic_types.h"
#include "xstatus.h"
#include "xgpio.h"
#include "source.h"
#include <sys/timer.h>
#include "checkppc6.h"

#include <stdio.h>
Xuint32 *baseaddr_p =3D (Xuint32 *)XPAR_CHECKPPC6_0_BASEADDR;
int main()
{
init_platform();
XASSERT_NONVOID(baseaddr_p !=3D XNULL);
baseaddr =3D (Xuint32)baseaddr_p;
CHECKPPC6_mReset(baseaddr);
CHECKPPC6_mResetReadFIFO(baseaddr);
CHECKPPC6_mResetWriteFIFO(baseaddr);
=20
CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // activate signal
=20
DataFPGA =3D CHECKPPC6_mReadFromFIFO(baseaddr, 0);
=20
}
=20
I donot see the initial value from FPGA IP until I send an empty useless va=
lue to IP input (which is CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); =
// activate signal). In my view a simple software reset (CHECKPPC6_mReset) =
should have initialized the IP and given me the output value I assign in AS=
SIGN_VARS case of my IP.
=20
My IP design is such that. IP asks the input of chemical molecules. then pe=
rform reaction and wait for ACK signal from PPC to continue with the next r=
ound.
=20
But the problems I face are. I have to (CHECKPPC6_mWriteToFIFO(baseaddr, 0,=
 0xffffffff); // activate signal) for no intuitive reason. Then when I prov=
ide ACK signal, IP doesnt move on to start Reaction again untill I provide =
another dummy input (CHECKPPC6_mWriteToFIFO(baseaddr, 0, 0xffffffff); // ac=
tivate signal).
=20
I believe next_state doesnot get updated, which is why it happens, can you =
guys please help me with this and suggest a solution.
=20
please see attached files for more info.


https://drive.google.com/file/d/0BxVHCJ7JxzSDa3lHb3YxdmhTLTA/edit?usp=3Dsha=
ring



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