[oc] CAN core

["Tan, Wei (CRD, Shanghai)" <Wei.Tan@geahk.ge.com>]

Hi,
 
Anybody can tell me if there is an open core for CAN interface?

Wei

-----Original Message-----
From: Richard Herveille [mailto:richard@asics.ws]
Sent: Thursday, April 26, 2001 12:17 AM
To: bender@opencores.org
Cc: cores@opencores.org
Subject: [oc] Fwd: (linear) bursts in Wishbone


Hi guys,

This is the email that went to Wade, before you started sending the emails 
concerning the problem.

richard



>Hi Wade,
>
>I've got a question concerning linear and non-linear bursts, or better 
>concerning bursts at consecutive addresses and random address bursts.
>When developing a bridge which is capable of doing burst cycles (like a 
>PCI bridge or a SDRAM controller), the bridge has to detect whether it is 
>a single cycle or a linear/interleaved burst transaction. There are two 
>problems to solve here; detect single cycle/burst transfer and ensuring 
>consecutive address burst transfers. The first is relatively easy, check 
>the CYC_I and STB_I signals; if they remain asserted it is a burst, if not 
>it is a single cycle transaction. The latter is more difficult and has to 
>be handled by the master, either by convention "all burst transfers are on 
>consecutive addresses only" or by a signal indicating 
>consecutive_address_burst.
>
>I prefer the last option for a couple of reasons;
>- All transfer cycles are supported; single cycle, consecutive address 
>bursts and random bursts (either directly for a SRAM or by multiple single 
>cycle accesses).
>- It simplifies cores using or relaying on bursts (like bridges), compared 
>to automatically detecting whether the bursts are consecutive or random
>-  It is compatible with linear and interleaved burst cycles
>
>I thought of using the WISHBONE TAG signals for this purpose, but this is 
>so elementary that I would like to suggest adding a signal which indicates 
>a consecutive address burst. The advantages of a dedicated signal over a 
>TAG are
>- Compatibility between cores
>- Mnemonic (nomenclature) compatibility
>- Overall support by all WISHBONE users, instead of a propriety TAG signal
>- Well documented behavior
>- Compatible with current WISHBONE specs.
>
>There's only one disadvantage to this proposal (as far as I can see), the 
>WISHBONE spec need to be modified (rev.b2)
>
>This signal, let's call it CAB_O (or whatever), can have the same rules as 
>the STB_O or CYC_O signals, as far as moment of assertion/negation is 
>concerned. Here's an example of a description of the signal:
>
>CAB_O
>The consecutive address burst [CAB_O] output, when asserted, indicates 
>that the interface is currently performing a burst transfer with 
>consecutive addresses. When negated [CAB_O] indicates either a single 
>cycle transfer or a random address burst.
>
>
>What do you think ?
>
>Richard
>