CPLD selection suggestion

[Altera_Forum]

Hi, 

We want to interface two devices (A and B) working at 148.5MHz.   The first device (A) gives out data at the negative edge and the second device (B) captures at the positive edge. The clock to output delay of A varies from 1.64 to 5.3872ns. The minimum setup and hold times required at B are 1.3 and 0.8ns respectively.   As per the timings, the ideal time for sampling the data will be at the negative edge. But as device B captures at the positive edge, the timings are not met when these two devices are connected directly.   So, we want to interface these devices through a CPLD. The CPLD will capture the data from A at the negative edge and give out data to B at the rising edge. Can you please suggest me some suitable CPLD device that can be used for this purpose?  Regards, Prachi

[Altera_Forum]

As FPGAs and CPLDs can only work on a single clock edge, you'll need a clock frequency of 297Mhz. I dont think a CPLD will be able to do that for you..

[Altera_Forum]

Hi Tricky, 

Thank you for your quick reply.   If we use a CPLD with an internal PLL, then can it capture at falling edge and give out at rising edge? In this case we can add phase shift to the clock signal.  Regards, Prachi

[Altera_Forum]

You could possibly do that, but you would essentially have 2 clock domains in the device, so you would need to pass the data safely between then, usually using a FIFO, so it will add a small amount of latency.

[Altera_Forum]

I assume devices A & B are not FPGAs whose logic you have control over? Ordinarily you would not design an interface, operating at that speed, to clock out on one edge and in on the other. 

 Assuming you simply want to clock data into and out of the CPLD at that speed then you have a pretty wide choice to chose from. The MAX V family will do that - you may need something faster than the slowest (cheapest) speed grade.  However, you are transferring the problem inside the CPLD. You now effectively have two clock domains inside your CPLD, across which you need to transfer your data. You will need to implement some form of FIFO to carry the data across between clock domains.  Regards, Alex

[Altera_Forum]

As Tricky and Alex pointed out, I believe the CPLD solution would transfer the timing problem inside the CPLD, with more delays to take into account. 

If it's simply a problem of synchronizing / changing the clock edge between device A and B, maybe including a single logic port (buffer or inverter) on the clock line driving one of the devices could make everything working. I don't know your actual design, so maybe this is not feasible in your case, because it arises other timing problems.

[Altera_Forum]

Hmm? 

I really can't see the problem here.  All he needs is to implement a chain of registers inside the CPLD. The first level of registers has to work on the falling edge, the last one on the rising edge. He'll need 3 or maybe 4 levels of registers to meet the timing between the oposite edges, but a MAX II/V should be able to do it.  Just try it in Quartus and see if can meet the timing constraint.

[Altera_Forum]

Yes, the problem is really there. Yes, you can clock the signal in OK and through a couple of FFs if you feel the need. However, at some point, if you need to clock it out on the other edge, you only have half a clock cycle to transfer the data between FFs. You would need to meet the setup time required of the 297MHz clock frequency that Tricky referred to.

[Altera_Forum]

Did anyone try to make a Max V project to document what he/she is saying? 

I did. And a Max V can handle the transfer of the negative clock to the positive clock edges for the internal registers. But it fails at both the input and output setup times as Max V doesn't have either input nor output registers. I had to switch to a Cyclone IV speed grade 6 to meet the interface timings.

[Altera_Forum]

Hi,  

 The Max V device (5M1270Z) has 1.5ns as the setup time, which does not meet my required specification. I require a device with setup time lower than 1.3468ns. Are there other options available? Or is there any other device in this family which will have a lower setup time?  Also, can you please explain why a 297MHz clock would be required?

[Altera_Forum]

The input and output timings are very close throughout a CPLD (or FPGA) family. 

There is no 'real' 297 MHz clock involved, but in transferring the data from the negative edge, used by input A, to the positive edge, used by output B, you only have half the period of the 148.5 MHz clock , which is 'equivalent' to a 297 MHz clock.

[Altera_Forum]

Pranchi, 

do not pay too much attention to the datasheet values, as this can be design dependent. You need to make a test design, apply timing constraints and see if it can meet them, as josyb did.  Would the I/O timing improve if you use the reverse edges? Ie, use the rising edge to capture the data and use the falling edge to transmit data? (I don't have access to Quartus right now)

[Altera_Forum]

Taking josyb's project, I made it meet timing with the MAX V by 

a) using the rising edge to capture A. b) applying a multi-cycle exception of 2/0 to paths from A. c) applying a multi-cycle expcetion of 2/0 to paths to B.

[Altera_Forum]

Thanks for the update. I now better understand multi-cycle exceptions. 

I played around with the code a bit. If I refactor 'B' into the clocked process in stead of using 'rb' TimeQuest says the design doesn't meet the timing. Anything fundamental I'm overlooking?  We can eliminate the 'rb' register and directly assign 'B' from 'ra'. This may possibly allow using a smaller device. I also played around using a variable -> same results.

[Altera_Forum]

It's a caveat with naming and name matching in the SDC. 

When you put the B assignment into the clocked process, you get a registers named B[...]~reg instead of rb[...]. These match the B* patterns in the multi-cycle exceptions, which causes havoc. The transfers from ra[...] to B[...]~reg are now subject to the same 2/0 multi-cycle and they can't meet the hold requirement.  If I had properly selected the paths, with [get_ports B[*]], you wouldn't have had such problem.