UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply
Scholar
Posts: 1,275
Registered: ‎10-10-2014

Design strategy for a HDLC controller - where to implement CDC

[ Edited ]

I'm designing a HDLC receiver interface. This interface looks very similar to an SPI slave, except that there's no external chip select coming in. Frame synchronisation happens using unique tokens in the data. 

 

So there are 2 signals coming into the FPGA :

 

  • EXT_CLK : in my case a few megahz
  • DIN : data synchronous to the EXT_CLK

After sync and deserialisation, data is written into a FIFO, for consumption by a processor.

 

I currently see 2 design strategies, and I'd like your opinion / advice / feedback on choosing between them, or even a 3rd strategy if there would be a better one. Feel free to comment to some or all questions.

 

strategy 1 : CDC using async FIFO

 

basically the entire serial receive system (FSM + serial shift reg) is implemented in the 'external clock domain'. A dual domain FIFO takes care of the clock domain crossing.

 

Q1 : in my application, EXT_CLK can be disconnected / reconnected in irregular fashion, with temporary 'glitches' on the EXT_CLK input → can this put the FSM into an unknown state when using this strategy?strategy 1.png

strategy 2 : CDC on the input CLK and data

In this strategy, the incoming EXT_CLK and EXT_DIN are considered as asynchronous inputs.

 

They are clock domain crossed to the internal FPGA clock domain (FPGA_CLK) using a 'CDC single'. The CDC of the clock is followed by an edge detector, which generates a single tick (width = 1 FPGA_CLK period) on a rising edge.

 

Once after the CDC's, the FSM, shift reg and both sides of the FIFO all work on the same clock domain.

 

strategy 2.png

 

Q2 : FPGA clock should be (a factor) higher than EXT_CLK_IN for this to work, is there some 'rule' that says it should be at least 4x, 8x, ... ?

 

Q3 : as an immediate conclusion to that, strategy 1 can probably run at a higher EXT_CLK frequency than strategy 2? Is that a reason why most designs on the web use strategy 1?

 

Q4: if I browse on the web and look at SPI slave implementations (couldn't find many HDLC implementations, and SPI slave comes close to this), I mostly see the first strategy implemented. However, this strategy of putting the CDC single on the input signals seems to be more rigid to me, especially when EXT_CLK could be disconnected/reconnected randomly. Or am I missing something here?

 

Q5 : I think another advantage of strategy 2 is that the FSM could transit multiple states during a single EXT_CLK cycle, hence having more 'flexibility' in FSM implementation.

 

Q6 : it looks like strategy 2 might use higher power than strategy 1, is that correct?

 

** kudo if the answer was helpfull. Accept as solution if your question is answered **
Scholar
Posts: 1,126
Registered: ‎09-16-2009

Re: Design strategy for a HDLC controller - where to implement CDC

Ronny,

 

I can see why option 1 would be the common solution you've found.  But I agree with you in your hesitation because of the non-stability of your EXT_CLK pin.

 

I would offer an option 3 - similar to 2 - but no special CDC circuitry on the DIN, and EXT_CLK inputs.  Strip it down to more basics of oversampling theory.  You're basically describing an oversampled UART.  (I'm not familiar with HDLC) - but given the synchronization tokens - you might not even need to sample the EXT_CLK pin.  Just oversampled 10X or so (I know 10X is and often quoted rule-of-thumb with oversampling.  I'm sure you can get away with less if you sharpen your pencil).

 

Even if you do need to sample EXT_CLK - I'd think stripping it down to basics would be simpler / better documented.

 

Note, I'm NO expert in sampling theory in this regard - I'm sure there's others with more expertise in digital sampling that can chime in.  But my gut tells me to Keep It Simple (S).

 

So not any concrete advice, just ideas...

 

Regards,

 

Mark

Scholar
Posts: 1,126
Registered: ‎09-16-2009

Re: Design strategy for a HDLC controller - where to implement CDC

Some good Xilinx App notes for oversampling (may be for older technologies, but should be a good starting point)

 

XAPP861, and XAPP224.

 

 

Regards,

Mark

Highlighted
Scholar
Posts: 421
Registered: ‎01-08-2012

Re: Design strategy for a HDLC controller - where to implement CDC

[ Edited ]

I've designed HDLC receivers (last century, so my recollections might be not-quite-accurate).  In my case, the HDLC stream was embedded in another stream, e.g. in a 64kb/s timeslot in an E1 (2.048Mb/s) or an HDLC ISDN d-channel (16kb/s out of ~160kb/s).  The system clock ran at some multiple of the aggregate stream rate (e.g. n x 2.048MHz) and there was an enable signal to indicate to the HDLC controller that this bit was "HDLC" as opposed to something else.

 

Getting back to the OP's question, this is similar to strategy 2 without the CDC logic on the front (since all the signals were already in one clock domain).

 

As an aside, the design I'm thinking of was much more complicated than that: it could handle multiple timeslots of HDLC from the same stream.  The state for each timeslot was independent and held in an external SRAM.  The SRAM was also used for packet buffering.  Each timeslot, the HDLC controller would fetch that timeslot's state from SRAM, decode some bits of HDLC (writing them to the SRAM if it had a full byte), then the state would be swapped back out to the SRAM ready for the next timeslot.

I was so glad when FPGAs gained internal memory.

 

Allan

Scholar
Posts: 1,275
Registered: ‎10-10-2014

Re: Design strategy for a HDLC controller - where to implement CDC

Thanks @markcurry, I read the app notes with great interest. I also discovered XAPP523 which describes the same but for 7 series and Zynq (which I'm using). And I just got XAPP1274 in my mailbox, which seems to go even deeper into the subject. 

 

Though this is all very, very interesting, I have the feeling it's somewhat overkill for my 'low speed' HDLC interface. It's in the range of 64kbits ... 2 MBits. So you can compare it with a slow SPI master interface entering the FPGA.

 

It's actually an SPI-like interface, with the SPI clock and SPI data are entering the FPGA, without the chip select. Instead of a chip select I need to search for unique patterns that mark the beginning and ending of a packet  (using a FSM).

 

With that extra knowledge (I should have explained this better in the beginning), would you still suggest to go for oversampling?

 

 

** kudo if the answer was helpfull. Accept as solution if your question is answered **
Scholar
Posts: 1,275
Registered: ‎10-10-2014

Re: Design strategy for a HDLC controller - where to implement CDC

[ Edited ]

thanks @allanherriman for your reply, that looks like some serious HDL project at that time :-)

 

indeed the HDLC is often embedded into other streams. In my case it's slightly different, I just get the HDLC stream with a clock, but no framing info. In some cases, I even need to generate the clock myself, or in other cases it enters with manchester encoding (don't know all the details yet)

 

So I was wondering how to interface with the clock and data signals, it's probably a 'common' FPGA technique, as it is similar to an SPI interface, but without the chip select. 

 

If I look at open source code for SPI slave devices (FPGA is a slave in my case, it receives the clock), most of them just use the clock 'as is', and perform the CDC in the fifo. But in my case the connection is unreliable, so the cable can get connected / disconnected at any time, and I'm worrying that my FSM might go crazy on that, and get stuck in an undefined state (cold FSM).

 

 

** kudo if the answer was helpfull. Accept as solution if your question is answered **
Scholar
Posts: 1,126
Registered: ‎09-16-2009

Re: Design strategy for a HDLC controller - where to implement CDC


ronnywebers wrote:

 

Though this is all very, very interesting, I have the feeling it's somewhat overkill for my 'low speed' HDLC interface. It's in the range of 64kbits ... 2 MBits. So you can compare it with a slow SPI master interface entering the FPGA.

 ...

With that extra knowledge (I should have explained this better in the beginning), would you still suggest to go for oversampling?

 

 


Ronny,

 

I don't know.  Use the synchronous, or asynchronous (oversampled) solution?  In the end, the difference between both is only engineering time - I don't think the resource differences between the two matters all that much.  I get that internal nag occasionally "am I overthinking this?" But then again, I've never regretted engineering a robust, reusable solution either. And, as bonus, you'll learn stuff along the way.

 

One of the troubles with being an engineer - the stuff that just works doesn't get noticed.  The stuff that blows up in your face (i.e. doesn't work reliably) - now that gets attention...

 

--Mark