News

Disabling PIN-code request

Disabling PIN-code request

The SIM-bank Polygator device has own software capable of performing some operations with SIM-cards from Linux-console (as the SIM-bank is Linux-based device).


One of new SIM-bank features is PIN-code disabling command. It is recommended to disable PIN-code request for preparing SIM-cards for the SIM-server. Command applied to all SIM-cards currently in the SIM-bank at once.


The command executed on Linux-console (directly on the device or via SSH) with PIN-code as parameter. PIN-code should be correct for all SIM-cards currently in the SIM-bank. After this all SIM-cards will have a PIN-code request disabled.


Why you may need it?


Most of SIM-cards ask PIN when inserted in a mobile device or commutated (in the SIM-server). One of standard SIM-server Polygator features is PIN-code auto-input. But in case you made mistake when adding a group of SIM-cards (with same PIN) to SIM-server Polygator you risk to have some or all cards blocked due to incorrect PIN. SIM-cards will engage internal protection and start asking PUK-code which is more complex problem to solve as all cards have unique PUK.

 

SimBank or 200 SmartCards in a box (full article)

As I already mentioned in my first Habr's topic about PCBs creation, my firm deals with various telecommunication devices such as VoIP, GSM, PBX gateways, GSM controlled rebooter sockets, etc. Today, I'm going to describe the process of SimBank firmware development in its PCI version where I had the role of FPGA layout developer.


Management tasks background + device development history

 

SimBank unit is designed for SIM (Subscriber Identification Module) cards, a variation of ISO-7816 cards. This unit may be used for centralized SIM cards or other smart cards storage to be used in such devices as GSM gateways, satellite television tuners or other devices which operation is based on smart-cards. Together with SIM-Server software, SimBank establishes a flexible system for recording and control of SIM cards you use in your applications, ensures huge capabilities of setting and configuring the system operation via a user-friendly interface. At the same time, the cards themselves are stored in an easily accessible location and are connected to terminals over TCP/IP.


There are other articles on Habr describing the design and procedure of operation with smart cards:

Brief Introduction into SIM Cards by OgreSwamp
Snart Cards for Little Ones by brake
A Smart Card Design by rlepricon


I read them all with pleasure before starting my own development. And I won't repeat anything you can find in these articles.

 

SimBank or 200 SmartCards in a box

SimBank Design

 

This design was created by my firm long ago and has been used successfully for many years. But there was one specific feature about all the firm's PCI units: a training PCI core that was supplied "as it is" without any claims accepted. Anyway, there were no claims. With just minor redesigning, this core was installed to all the boards without any exception. This helped using the available address space intelligently. With one and the same Vendor ID, Device ID, Class Code. As the units were usually assembled at the firm and passed the functional tests, no conflicts were reported. With some time restrictions, the principle "do not touch if it works" is quite a smart approach. This was Ok until some contemporary mother boards started to show unstable operation or even failed to launch.

 

Time has come to pay more attention to the PCI core. The training core adjusted for specific tasks was documented and commented, but these comments were not always sufficient. The link for its location dated 2002 or 2004 was inaccessible.
The task was more than simple: "The unit must work on all the standard boards."
And a bonus: "Even if not all 200 SIM cards are used, but 196 or 1хх."
Until that moment, I've never worked with SIM cards or PCI bus as a FPGA developer. Just a circuit and a board. I had some experience in VHDL and Verilog.
It was decided to set for the development from PCI as the part related to SIM cards was operational.
The familiarization with PCI Local Bus specification did no miracle and did not cast much light on the path to go. Having read multiple articles about do's and don'ts, but still having no clear picture in mind, I decided: "just start, then I'll figure it out."
There is a Megafunction for Altera PCI in Quartus environment that allows for generating a PCI core with the required parameters. The core is attached with detailed documentation and there is the PCI kit description on the web-site with PCI model of behavioral simulation in ModelsSim-Altera. All this together is a great help for those starting from the scratch.
Moreover, Altera allows using its Vendor ID (1172h).
In PCI specification, a unit class unavailable in earlier specification versions was selected: 07h – Simple Communication Controllers, 05h- Smart Card.
Then, everything should work in Linux. As my colleague was more experienced in SIM Cards and PCI, he was the one to develop the technical specifications. And all my thanks to him. Properly compiled specification is the half of the task. Though, it requires "additional writings."

 

Material studies

 

As it was not me who designed the unit, I had to study its circuit and board layout.
The circuit is necessary for understanding the links and connections and the board helps to know where to plug the programmer, SIM cards and where to look for any service indication. Later, I will tell you about a low-down trick it played with me.

SimBank or 200 SmartCards in a box

For the circuit, we have a board with two Altera Cyclone II EP2C35672C8 FPGAs in a housing with 672 contacts. One FPGA is connected to the PCI bus and controls the second PCI. 100 SIM card holders are attached to each FPGA. Each SIM card is linked with its own reset and data signal, and CLK signal comes to a group of 10 cards.

SimBank or 200 SmartCards in a box

Each EP2C35 microcircuit contains 105 M4K units of built-in memory. Generally, RAM unit (including parity bit) has 4,608 bits.

 

Units support various configurations from 4K × 1 to 128 × 32(36).

 

On top of this, I wrote a document with additional questions about the transmission sequence and various signals duration regulation, and about verification of the incoming data from SIMs and other questions.

 

Having make it clear about the contacts of the first PCI bus from the microcircuit, I made a pilot project of the PCI core in Quartus that was supposed to work with new bus parameters. Without any logic – just a core.
After I received the response to "lspci -vv”" command, I felt myself the happiest man in the world.

SimBank or 200 SmartCards in a box

 

Then we discussed with the driver and application developer our future actions and made a pilot project in which the driver wrote the data to its memory and than read them and checked. Initially, only the first microcircuit in the layout was checked.
Then came the second microcircuit detailing.
36 signal lines + 2 lines between PLL_OUT and CLK output are designed between this two microcircuits. The previous project used 19 address lines and two bytes for the data exchange (one per each side), read signals and write signal. This was determined by the features of the existing core. And by the consideration of the driver and software unification. So, for example, there is an established set of addresses where you can take any service information from.
ARM versions store the following info type:

SimBank or 200 SmartCards in a box

 

 

Elgato G4_1 is the unit type (“K16” or “К32” for PCI cards, “SimBank” for SimBank);
SIM51215 (SIM900 or other) is the type of the installed GSM or 3G module (required to select a proper set of AT commands). Its relation with the described unit is the selection of a SIM card to be connected to the operator's network via the given module.
2014 is the year of development;
ver.14.144 is the firmware version;
SN: 0123

 

If it is not changed to the correct version before the firmware installation, these data may help to learn many interesting facts form the "register" stating the project customer and any deviations from the standard the customer wished.
For SimBank, only a serial number is sufficient as, functionally, there's always just one SimBank card in a unit. And in PCI version, this card is just one for the firm.


Painful Decision

 

Earlier core version used two BARs. BAR1 was mapped in 1М memory, BAR0 was used as 4К input-output registers. All the address space was assigned to both FPGAs simultaneously.
It was decided to refuse IO application for different reasons. First, it is much easier for the driver developer to work with the memory. Second, there are many recommendation in the Internet explaining why it is advisable to refuse from IOs in new developments. Third, the IO resources available for setting in Altera core is restricted by 256. Memory resources are much bigger. But this transition required changing the SIM card operation principle. And implied almost complete re-working of the exchange module for SIM. In addition, moving from a traditional addressing meant we would not be able to read the required bits in a customary location using any of our typical programs.
We could refuse from making two base addresses and get along with just one. We could do without one timing signal saving at exchange with the first microcircuit cards. This data exchange portion is not responsible for voice transfer and we do not need to save milliseconds to get not more than 20 ms delay. Anyway, I believed this would be right.


Structure

 

After the first success and verification of the text data writing into the memory, the time has come to build the structure of data exchange with the SIM cards. I had some general understanding of this process, but after the tests, I was ready to suggest it would work. An the tests I elaborated and conducted turned to be useful.
The existing 36+2 lines were insufficient for broadcasting the service signals of the PCI bus to the second microcircuit without changes, and I was unwilling to restrict the receipt and transfer by one or two bytes. Even if I manage to separate address and data buses.
Therefore, 32 of 36 signal lines were allocated to the data (and address) bus from the very beginning, 1 signal line controlled the general system reset and the other three were loaded up with all the control functions. We had a separate line to transmit CLK signal.
Silent mode, address transfer mode, single data writing mode, data threads (burst) mode, masks writing modes, reading and threads reading. Total of eight bus conditions that we managed to put into three signal lines.
There still were four BE signals to be transmitted for mask writing. We decided to hide them in four higher bits on the data bus if we use such a mode.

 

For each SIM card in the FPGA, a maximum possible buffer was allocated. Taking into account that a single-way half-duplex interface was realized with a smart card, that we had 100 cards and total of 105 memory cells in the microcircuit, it was decided to make just one buffer for receipt and transfer, and reset addressing in the beginning of any receipt or transfer. I was lucky, and it was a standard limitation for a SIM card to send not more than 256 data bytes per a command. Therefore, the available buffer won't get overfilled before we can read it.
Here, "command" meaning is a bit different from that of ISO-7816 standard. The standard takes it as addressing the card, then receiving the confirmation from the card and then data receipt. But I was interested in the data amount between the buffer resettings.

 

It was decided not to make a buffer for the data exchange with the second microcircuit, but to make an immediate record in the SIM card memory in the second microcircuit. Because 102 of 105 memory units were already occupied. The selection between the first and the second microcircuit was made via addressing BAR0 or BAR1, respectively.
Different controllers were provided for BAR0 and BAR1. The second microcircuit is addressed during the next clock period, but this is adjusted by TRDY signal delay setting at the PCI bus.

 

Each microcircuit has 64К of memory which is sufficient for 128 Smart cards processing. We have 100. 28 units are left. So, we locate some service information in two units such as the information about the card resetting condition, the exchange rate. In return, we need to get the number of data received from the SIM card.

 

Then, everything should be made operational and debugged. As a project for 100 SIM cards takes very much time for compiling, and it's much more expensive to burn our 100 SIM than say 1 or 10, we decided to debug exchange between 1 to 5 cards first and then add all the rest. Moreover, to debug only the first half and then, after we decide that everything's ok, to go to the second microcircuit.
It was here where a surprise awaited for me.
There is a circuit with cards contacts numbered 1 to 100. There is a board project with successfully imported FPGA contacts settings (PCI is operational, test memory record works and the exchange between he microcircuits is ok). The project is compiled of 5 cards, to have at least a second card working if I am wrong with numbering from 0 or 1. Not a bit of it!
Ok, we have 10 LEDs on the board. Though I planned to leave them for the end, I had to move my plans a bit closer. We add a simple thing for the LED on-off, but the lamp does not lit LED does not flash.
So, we take an oscillograph. There's a CLOCK, but no reset. No data, too.
Is anything wrong with the data import? Let's check the circuit against the board, then the board and circuit against the Pin Planner in Quartus. They match. But there's still no reset.
It is the moment my more experienced friend comes to help me. He says that “a princess is in another castle” “SIM0” is at the other side of the box in the program. And it always was there.
Here you can screen shot a piece from PCB project to P-CAD. There are signal name plates there.

 

On the board, SIM 199 is used, and in the project, it is SIM0. The project is compiled for 5 cards only. (It is not big enough yet for 100.) And therefore, the rest 95 cards are just not served. For them, even no FPGA memory buffer is created.

 

To save the resources, it was decided to time the memory units with the frequency of SIM cards. This will help to reduce the number of dividers. Besides, with a lower frequency, it will be easier to fit into the speed resources of the microcircuit. At the same time, it was planned to write the SIM buffer at the PCI bus frequency (33 MHz), and to read it at the SIM card operation rate. Due to the restrictions of two port memory, we had to look for other solutions in Cyclone II. So, the easiest and rightest solutions turned to be timing of all the units with 33 MHz frequency from PCI_CLK. And for reduction of the number of multidigit counters, we had to use permission signals for registers timing. In addition, this approach allowed for easier writing of time restrictions for TimingAnalyzer via multycycle.

 

Model setting. For the success of any invention, we need a model. For the PCI core, this model is represented by Altera. For Smart cards, we had to write a model ourselves.
The disadvantage of this solution is if I understand the SIM card operation wrong, I will write equally wrong model. But it worked. Though, not from the very first time.
Simulation helped me not to become a nuance for my colleague, though afterwards, we had spend much time solving the hardware problems while debugging. What is wrong in the model and how it should be.


T0/T1 or never try to make it better, make it right

 

Initially, in automatic SIM card operation, the SIM card resetting and reading from ATR was debugged together with rate change and a simple command "A0 A4 00 00 02" sending with the response of "A4" for all of these. I wanted to make an automaton that reads everything itself at switching on and operates at a maximum SIM card rate by the moment of OS launching. This would help to unload the program when initializing two hundred (200!) SIM cards at the start.
Some SIM cards worked nice, but others were stubborn returning h’3B and staying silent. As a result, a timer was tripped automatically and I reset the SIM card as it failed to tell me the rate I could talk with it. If I received three or more than three bytes, I believed the ATR was read and I could go on working. Though the model worked perfect, it turned out that different SIMs give different ATRs. Some give all the information at once, while others set a pause after sending a heading of h’3B and only then give the necessary data. Bigger pause solved the problem. For a while. There are SIMs that send a final bit with the same long delay as in the beginning after h’3B byte.
It is solved, too. No smart automatons, spontaneous rate changing over and other things. It's the task of the processor to think of this. It must make a decision about when to give a reset, when to remove it and decide when the data portion from the card is finished.
But there's a problem. We still did not set all the goodies, and we can fit only 80-85 SIMs out of necessary 100 in each microcircuit. Let the operational system driver do this. It's not a big task for it, and we feel better.
Then we set about debugging other commands we already received from the OS driver. Debugging on a big number of cards. And new "discoveries" awaited for us.


197 of 200

 

Where is the solution if 197 of 200 of cards are operational, but three are not? Is it an accurate operation? We debugged this on SIMs blocked by the operator that still gave responses to resetting and pretended they write SMSs to them. May it be that these three cards are blocked intentionally and they are mistaken? How naive I was.
The first real operation showed everything was correct at their end. I had to search.
And I found. Not soon. Again, a colleague of mine helped who arranged exchange logs for all the SIMs. And it turned out that my counter skipped sometimes when writing big commands. So, I wrote the same byte twice in the middle of a long transfer. As behavioral modeling is a long process, I did not use long commands in the model. Only short transactions. I used reduced counters. A step ahead, model, check, works. A small victory! And so on. A bit is written, then a word, a double word, A couple of addresses are passed – hopefully, everything will be ok.
As a result, it works with a small model, but stumbles in real life. At the same time, the SIM card has the time to give its number (if written in it), ICCID, IMSI or whatever else before the error. And when simulating writing/reading to/from the SIM card, it does not demonstrate utmost stability: three of 200 cards give errors.
Manual comparison of the program log with the logic analyzer showed the error resides in the SMS body. And 197 cards overlook this error when counting CRC. They are unwilling to spend their efforts for SMSs, though three cards celebrate their hour of triumph.
I updated the model and launched it, and it again was ok. How could it happen?
I start the model with complete counters check (divide 33 MHz by 6, then by 372, then so on and so on, instead, suppose to divide by 4 and then by 16). So, we start the model in the evening hoping to see everything in the morning...
and in the morning, we find out OS sleeping calm and quite. The screen used to switched over to energy saving mode. But it never slept. After 4+ hours of modeling of more than 300 signals and buses, it fell asleep "in its shoes". And started only at the third attempt in the morning. Though, I was lucky enough for I was saved from the necessity to restore the whole system.
A day of work, sleep is switched off. And the next morning, I was happy finding the error. To be honest, before, it took me a day to deal with various other tricks. On my happy day's morning, I guessed where to find the error.
It was not the last – there were others, more evident and easier to correct ones.


Laying the mosaic

 

Assuming the smart card operation is stable, I connected the second microcircuit. First, in the project. Then, in the model. Then, in the hardware. Not at once, but we did this portion, too. How to verify all the 200 locations work simultaneously and do not interfere with each other? Where to take so many SIMs? We scraped the corners and found 200 cards. Model was launched.
Launched and set to testing. And a new surprise. If all the positions in a SimBank are occupied, it works good. The cards are stable, resettings are rare. But, if some cards are not installed, a resetting command comes to their positions regularly. And sometimes, the symmetric cards in the neighboring FPGA are reset, too. Why?
I still cannot answer this question. But now, I know what Signal Tap II Logic Analyser means in Quartus by Altera. We used it to retrieve the signals conditions in the PCI bus via JTAG. Changing the project and creating new signals to start or stop counting, we managed to look at some parts inside FPGA. So, for example, I was surprised to know that Burst mode almost never was switched on when reading or writing more than eight bytes. Absolutely never for writing, and not more than two PCI clock periods for reading. Though the program sends command "read 40 bytes", reading is processed by four bytes from setting the address on the PCI

SimBank or 200 SmartCards in a box

Resetting problem was partially solved with program tools at the driver end, partially by restricting the usage of odd number of SIM cards in the bank until better times.

 

A question to the readers: Is there any possibility to write all the logs of a device calling in Linux (Centos 6 32-bit)? It is desirable, though, not to interfere with the PCI bus operation. So that we could set a Vendor ID/Device ID and store its R/W calling logs in the bus?


Conclusion

 

Finally, fully updated project in FPGA spends 89% of logic elements and 85% of available internal memory. Everything fitted and this means the elementary base and structure of the project were selected right.
The circuit helped to save two 50 MHz generators as the project takes only 33 MHz PCI time signal, they are not used and may be not installed on the board in the future. The project works with any of the mother boards that may be found today.
The unit may register all the cards in the network simultaneously provided there are enough GSM channels.

 

Now, in addition to updating the firmware and drivers at out customers, some units are working in our facilities. Some send SMSs for SprintSMS project. The others are "guarded" by our technical support and serve our customers. This helped us understand the essence of our customers' work and what they really need, from the point of view of both ergonomics and additional software functionality. In addition, the unit that works good (not jinxing it!) helped to increase the quality of the software debugging.

SimBank or 200 SmartCards in a box

But this is another story.

 

My thanks to everybody.
To the readers for their interest to the article. To the authors of the other articles for useful lessons. To Habr creators for Habr. To my colleagues for their help and experience they shared with me. To my manager for understanding.

 

P.S. Bonus: SimBank visual control web interface picture.
Special thanks for it to Maxim.

SimBank or 200 SmartCards in a box 

Here, SimBank is launched in 100 cards mode.

SimBank or 200 SmartCards in a box

The list of cards with the information read from them. For the cards, that require PIN code, some information is unavailable.

SimBank or 200 SmartCards in a box

 

Web interface is available from a smart phone, too.
The cards that are in operation right now are highlighted yellow.

Global tech.support address

Global tech.support address

Buyers and resellers of Polygator equipment can use global email for getting technical support This email address is being protected from spambots. You need JavaScript enabled to view it. .

 

 

You can send support questions to this email accompanied by device and client detail. The request will be processed and assigned with a unique number (ticket#) followed by support team reply.

 

Our article at habrahabr “SimBank or 200 SmartCards in a single box”

Our article at habrahabr SimBank or 200 SmartCards in a single box

 Please have a look at our article at habrahabr-website about the development of our device – the SIM-bank. Currently it is in Russian, but will be available in English soon – you will be informed via newsletter.

 

SIM-bank paired with GSM/SMS-gateways allow to manage hundreds of SIM-cards flexibly. It enables the owner to create Voice/SMS-services and other solutions in the field of telecommunications.


SIM-banks, GSM-gateways and other Polygator equipment are result of own research and development efforts of our company.

VIDEO - Testing of IP-PBX based on GSM-gateway G20

VIDEO - Testing of IP-PBX based on GSM-gateway G20

GSM-gateways Polygator are universal telephony devices. They can be used not only for converting GSM to VoIP but also for mini-PBX tasks.

 

 

For example, IP-PBX Asterisk can be installed on gateway and set up for dozens concurrent calls. Following video shows what happens to gateway (24 channel model) when making 24 concurrent calls from SIP to GSM.

 

 

YouTube video address

 

Test conditions:
- 24 concurrent calls, codec G729 and G711A
- every call makes real load: outgoing traffic is generated by audio-file and incoming traffic generated by auto-responder of mobile operator
- GSM-gateway system resources load is traced with Linux-utility TOP installed on the same gateway
- calls quality is evaluated by software StarTrinity SIP Tester by various jitter statistics
- Asterisk started in «directmedia» mode, NO voice recording on Asterisk is performed

 

 

If you want to see any other test – tell us by writing to This email address is being protected from spambots. You need JavaScript enabled to view it. .

 

Participation in «Corporate Communication Systems» conference

Participation in Corporate Communication Systems conference

October 15th, 2014 the conference «Corporate Communication systems» (Kyiv, Ukraine) took place. Company Polygator successfully demonstrated own equipment, held negotiations with telecom specialists and established new contacts with customers and partners.


We thank all visitors and organizational team for a great event!


We keep you informed about similar events where our companies participate and we can meet via newsletter.

 

 

Compact SMS-gateway All-In-One

Compact SMS-gateway All-In-One

 

SMS-gateways Polygator – are universal "boxed" solutions for SMS-server implementation. By “universal” we mean these gateways are Linux-computers open for custom tuning, adding and modifying scripts, libraries, etc.

 

 

Default set of features includes support for SMS-protocols and technologies as follows:
1. SMPP - with multi-threading support
2. Email-SMS, SMS-Email - Email-address(es) set up individually for each SIM-card (GSM-channel)
3. HTTP - by processing HTTP-requests and parameters (POST, GET) via on-board scripts
4. Customs open SMS-protocol (interaction with the device via the Telnet commands on port 9005)

 

Interesting features:
5. Events - when some Event happens (incoming SMS or Call) device will trigger SH-script (Shell-script, Bash-script) and send to it all Event-parameters. The script can be customized to report Events to external servers, etc. Useful for QoS control.
6. SIM-server, SIM-bank support (additional option) – provide rotation of SIM-cards in SMS_gateway on certain rules (for example after consuming daily SMS-limit on SIM-card).

We have highly positive experience of using our hardware with many famous software products like: Ozeki, Diafaan, ActiveExperts, Kannel, SMS Server tools and so on.

You are welcome to get more info about our SMS-gateways and get remote access for testing purposes as well as our online consultation and advice on integration and possible application.
Do you have any special request (like STK support)? Let us know!


Product link

Our story: Development of circuit boards for small-scale production

There are many articles about setting and supporting VoIP and accessories. There are also some articles about printed circuit boards development. Other articles give hints on do-it-yourself PCBs made using laser etching. Read, for example, Laser Etching on Vynil and Homemade Arduino Mini. There are descriptions of various PCBs designing systems such as Cadence, Eagle, DipTrace or description of individual processes when developing PCBs such as information transfer from Altium to AutoCAD.

 

Here, I'd like to post an article about PCBs serial production based on the experience of a company and my own experience gained in other work. My task is to upgrade the existing PCB and improve the existing features and, possibly, to discover new, unprecedented horizons.

 

CP card coded as "G20" was taken as the basis.

 

Later, this board became the core for many developments of the company. It will be used with attached boards in various configurations. Several developers are engaged in the projects for these boards and each of them manages his own core and add-on PCB.

 

Many years ago, long before me, my company has developed a wonderful board, which, thanks to its sophisticated design, became a core for many firm's devices. The choice was made in favor of Atmel ARM9 G20, and Cyclone III by Altera was selected as a FPGA (field-programmed gate array) to connect with other boards. FPGA and CP connection is established over parallel bus compatible with the processor memory bus.

 

The processor operating frequency is 400MHz, two SRAM microcircuits for 512 Mbit connected over 32-bit line bus are installed on the board. In addition, fast Ethernet 10/100 and 2 host USB are installed on the board and may be used both for program downloading and for connecting Wi-Fi, network adapter and other devices. The board also contains PRI microcircuit to allow Е1/Т1 flow if connected to the telephone network.

 

The board is equipped with connectors for auxiliary cards. One card may be connected on the top (as a mezzanine) and two cards may be connected at the sides. Connectors are of double row type 2.54mm spaced, for through-hole soldering. The benefit is the board's affordability and availability in stores, market places and bins. The same concerns the counterparts. The disadvantages are related to its big size; due to big spacing between the contacts they have less connection lines, soldered through-hole components require much space for routing in all the board layers, and the connectors for the top card divide the board into three parts. Through-hole assembly allows for a connector orientation both upwards and downwards. Though, all the cards are usually installed over the core board.

Development of circuit boards for small-scale production

Several submodule card types that may be structurally connected using mezzanines were developed for this board. In addition, the cards may be connected at the sides of the board using adapters.

Development of circuit boards for small-scale production

 

One of such modules is GSM card for four or eight channels. Removable mezzanine allowed for development of cards for various GSM modules by different firms and manufacture cards for several ranges (GSM, UMTS, WCDMA). Moreover, it allowed for installation of traditional telephony cards and for wider features PABXs. A version with SIM bank for 100 SIM cards is available.

 

Dividing functions between several cards allowed for individual cards setting and making upgraded mezzanine models later.

 

In addition, the board is used for debugging and testing individual program modules for future systems. EvBoard may be connected to its contacts to start debugging before your own PCB is made.

Then, the capabilities of the main card turned to be insufficient and it was decided to develop a new card instead of the existing one. Parallel bus restricted the data exchange speed and the number of simultaneously loaded cards. Thus, the requirements to a new board were formulated.

 

This board must have larger RAM, separate bus between the memory and FPGA, must be able to use fast serial channels to communicate with the cards and, preferably, must have PCIe. At the stage of components selection, additional requirements were set: built-in programmer for FPGA, two Ethernet connectors, USB-hub, HDMI, compatibility with the old PCBs. Some interfaces were included as individual connectors to connect devices in a loop.

Development of circuit boards for small-scale production

The analysis of the available processors showed iMX6 by Freescale was the optimum. Compared to its competitors, all the documents for the processor are accessible and sane, as well as the recommendations available without a prolonged NDA signing, its BGA housing is suitable for "simple" soldering, it has an "ordinary" memory bus, floating decimal point support and a number of other advantages. It was not me who voted for ARM Cortex-A9 core, floating decimal point support and other goodies. So, we got a compromise between the possibilities of state-of-the-art mobile technologies and the production capabilities.

 

Circuit was derived from one of the debugging components and upgraded for our needs.

Development of circuit boards for small-scale production

Selection of connectors for side cards is also a compromise between the desire to get multiple parallel and serial signals and the price for connectors. A pair of them may cost over USD60. The decision was made in favor of PCIe end connector. In future, this may help to reduce cost by one connector per a pair of cards. Moreover, this connector will support fast signal transmittance up to 3.125GHz as in Cyclone GX.

Development of circuit boards for small-scale production

 As it's not necessary to use E-Ink display, FPGA was hang to the processor parallel bus, PCIe processor bus was connected additionally together with 1Gbit FPGA bus via a high speed key. Now, our processor can send PCIe either to FPGA or to one of the side connectors. In addition to PCIe x1, four 1Gbit channels per each side are connected to the connectors. They are supposed to be used for "fast" connections in future.

Development of circuit boards for small-scale production

3D simulation in a design package helps to avoid "closing" of critical connectors by other cards.

 

Then, we had to put everything into the set board size, but leave room for future field adaptation using "solder-do-not-solder" scenario. This approach allows for making a sophisticated PCB by outsourcers and adapt in for the customer's interface in house. As a result, a customer does not pay for the things he does not use. These restrictions prevent from making a compact structure sized 0201 ensuring close contact between the components. In addition, sometimes, signals need to be led outside in order to solder a bridge. This is the price of flexibility.

 

Therefore, other ways to save the space should be searched for.

 

For example, similar rating and voltage condensers may require more room by height or by area. Many microcircuits are produced in different housings and may be a significant space saving factor with similar functionality.

Development of circuit boards for small-scale production

SOIC and QFN housings for DC-DC converters make great difference. DDPAK and TO220 housing are giants compared to them.

 

Texas Instruments has different types of step-down DC-DC. But modern converters can work on higher frequencies and require lesser inductivity value. With 1-2А current, 12…18uH inductivities may be found in acceptable housing sizes. If 5A current is needed, inductivity size becomes too large. Selection of another converter may help switch to 1...2uH inductivities and match the required dimensions. Both by area and height, and by weight of the components.

 

When designing a printed circuit board, the components interrelation should be taken into account and it is necessary to separate sensitive circuits from the sources of interference. Which, by the way, may be pulse DC-DC converters. Therefore, using shielded inductivities, compensation circuits and placing the auxiliary power sources far from the sensitive circuits may save your temper in future. When these elements cannot be separated in the PCB, various manoeuvres are required to reduce the signals effect inside the PCB.

Development of circuit boards for small-scale production

Here, you can see the ground layer area near HF connectors inside the power layer on a GSM gateway PCI card.

Development of circuit boards for small-scale production

 

Cut out in the inner ground layer to reduce the interference between digital and HF noises on a GSM gateway PCI card.

 

It is worth mentioning that a PCB routing for laser etching manufacturing and factory manufacturing differs.


The requirements to the components installation also will be different.
With small production batches or single prototypes production, the assemblers requirements may be like these: "I need a PCB and its components, if you have a template for SMD components installation – give it to me". Often, it is enough to have an assembly map where the components positions are marked in different color or sometime simple position designations are used. Without any accurate coordinates. Below is a piece of such assembly drawing.

Development of circuit boards for small-scale production

 

If we are going to make a sophisticated PCBs or simple but big PCBs, we better deal with reputable outsource assemblers. They have the equipment for both the assembly and testing of the assembled cards. However, they have more strict requirements. Requirements to the PCB quality, template, components and even to the routing.

 

Process margin may be required at the PCB edges to ensure the card movement over the conveyor. This margin size depends on the manufacturer, and our manufacturers are happy with 3...5mm. If no components are installed at the card edge, process areas may be unnecessary. A card will move over the conveyor resting on its edges. For PCBs with uneven outlines, process margins may be required for smoothing the outlines to ensure the card movement over the conveyor.

 

Additional outfit may also be necessary to apply soldering paste. For projects with surface assembly elements, a template is usually used as such outfit. If you plan a big batch of PCBs or your PCB won't be a unique one, it's better to add library components "for production" at the early stage.

 

Saying "for production", I mean both assembling and the boards manufacturing.
For assemblers, it is important that all the components have right seats.
Component seat is usually slightly bigger than a soldered element to leave gaps for correction of inaccurate positioning. But, at the same time, they should not be too big. On big boards, small components may be shifted and we will have poor quality assembly. In addition, there may be too much soldering paste on a big board and, when melting, boiling flux may raise a component and put it on the side. However, with a big contact site and a smaller template hole, solder may spread over the board and won't get to the component leg.

Development of circuit boards for small-scale production

For components with spacing between outputs less than 0.5mm, it is recommended to size an opening in the template for soldering paste smaller than the contact site to prevent from squeezing out of the soldering paste by the component and from short circuits and bridging when fusing.

Development of circuit boards for small-scale production

 

Red line on the figure shows the soldering mask opening boundary, violet line shows the contact site, and black line shows the hole in the template for soldering paste.

 

Today, the components are more often made in smaller sized housings and, despite high efficiency, the problem of heat removal from the microcircuits is a big challenge for the developers. So, if a housing size is small, it is impossible to remove the required quantity of heat through the cover, therefore a tricky move was invented: the microcircuit's bottom is soldered to the board and then the board takes the responsibility to remove heat over its copper layers.

Development of circuit boards for small-scale production

 

Development of circuit boards for small-scale production

 

I had a practical chance to test the efficiency of such cooling technique: there were microcircuits with unsoldered bottom in which thermal protection used to trip, though after soldering the bottoms, the microcircuit temperature reduced while the board temperature increased and even connectors became warm as the heat was now removed to the ground layer the connectors housing were soldered to either.

 

So, read the recommendation for such microcircuits seats designing thoroughly for some of them do not have another ground contact but their bottom. And if you do not put soldering paste under the contact, your microcircuit won't be electrically connected with the ground. For microcircuits with small number of legs, the thermal pad under the housing has small size, while with big microcircuits, caution is required. The manufacturers give their recommendations as for the area of the contact site and the size of the template hole for the soldering paste. Sometimes, the documents simply state 60–70% of the thermal pad area and sometimes, it is recommended to divide a big window in the template into several smaller windows to prevent from soldering paste squeezing out from big holes. The same is recommended for bit contact sites for other components such as for big inductivities.

 

For the component assembly system to work properly, it needs a reference point on the board and the components assembly coordinates with the turning angle. More details you can find in search results by "PCB fiducials" keyword. File with coordinates is prepared in PCB designing software automatically.

 

In the end, I usually have a file like below with tabulations:

 

Header:

 

$HEADER$
BOARD_TYPE PCB_DESIGN
UNITS MM
$END HEADER

 

Part with components:

 

$PART_SECTION_BEGIN$
R303 RC0402FR-0768KL 270.00 120.30 39.10 BOTTOM YES
C580 CC0402-KR-X5R-5BB-104 180.00 38.40 88.50 BOTTOM YES
VT3 NDS331N 90.00 56.80 26.40 TOP NO

C282 CC0402-KR-X5R-7BB-104 180.00 128.10 26.20 BOTTOM YES
VS2 BZT52C-3V3 90.00 71.40 27.10 BOTTOM YES
U23 MCIMX6Q4AVT08AC 0.00 106.00 45.90 TOP NO
$PART_SECTION_END$

 

Coordinates with fiducials:

 

$FIDUCIAL_SECTION_BEGIN$
BOARD 42.50 8.00 BOTTOM
BOARD 177.00 8.00 BOTTOM
BOARD 183.40 113.50 BOTTOM
BOARD 183.40 113.50 TOP
BOARD 177.00 8.00 TOP
BOARD 42.50 8.00 TOP
U23 94.50 57.40 TOP
U23 117.50 34.40 TOP
U10 22.70 87.00 TOP
U10 38.70 109.00 TOP
U18 52.50 69.50 TOP
U18 81.50 98.50 TOP
$FIDUCIAL_SECTION_END$

 

For small sized PCBs, a group blank or a panel is the beast layout option. This requirement is set by both PCB pad manufacturers and the assemblers. For assembly, coordinates of components for one PCB, cards spacing in the blank and the card angle in the blank are provided.

 

PCBs require rotating mostly for reducing the bank area in case of an uneven PCB outline. At the same time, rectangular boards also may be rotated in the panel. Once, our assemblers demanded increasing the process margin from 5mm to 30mm for one of the board sides as there were components to be installed with a very small spacing. After grouping the boards into a panel, the problem edge was turned inside and the process margin was kept 5mm everywhere. This allowed for placing two panels in one big glass fiber sheet at the production stage. And the customer was able to keep his costs at the level.

Development of circuit boards for small-scale production

Gas flow meter boards manufacturing panel.

 

After assembling, the boards may be separated either by the assembler, or easily by us. Then goes testing, firmware installation, setting, housing and pre-sale preparation.

 

These are just several stages of the boards and devices preparation for production. They may be supplemented by components list minimizing, manufacturability testing, housing design and components positioning on the board together with other operations, but I tried to describe the operations I used to do personally.

 

P.S. I do not have a photo of a new board, as it's not delivered yet. Currently, a new board is developed in the old board size based on the new layout and without unnecessary fancy things such as a display, expensive FPGA, etc.

 

Circuit > Board > FPGA

There are articles on Habr for FPGA beginners, there are articles with PC board layouts. I have already referenced some of them in my first article on PCBs building. In the comments to my second article about SimBank, I had a discussion concerning the difficulties of FPGA development and supporting projects with it. There was an opinion that it's much easier to compile several simple devices instead of one complex unit. Sometimes, it's really true. When it goes about two, four or eight devices. And so on with a usual multiplicity. Until a comfortable limit is achieved. Is two too much? And what happens if you need 100 or 200 similar devices?
To use FPGA or not in any task is the question to be answered by the developer himself (or together with the colleagues).
Today, I want to talk about the specificity of an FPGA PC board creation. Let's take IO Designer tool by Mentor Graphics as the starting point.

Circuit > Board > FPGA

 

Some may find my article useful, some may think it's simply interesting, but there will be guys who may not agree with me.

 

For some CAD systems, such as Altium Designer, regular updates appear with new microcircuits data bases. (If you are subscribed for the updates.) For Cadence and OrCAD, the manufacturers often publish the library elements of circuit symbols and cells for PC boards. For ExpeditionPCB by Mentor Graphics such luxury is rather an exclusion than a rule. As for PADS (another product for through designing of PC boards by Mentor Graphics), I have nothing to say as I've never worked with them. The designing system itself has a very convenient library components manager. There is a very good program, LP Wizzard (Land pattern wizzard), to build the component seats on PC boards according to IPC-7351 standard requirements. To create graphical circuit symbols for simple and more complex components, there is the possibility of import from file. And for FPGA, there is IO Designer that combines symbol, circuit, board (for the PC board) and Verilog(VHDL) project sections.
IO Designer contains the data base for most of FPGA and CPLD by such manufacturers as Xilinx, Altera, Lattice and Acctel. With MG, the appearance of new FPGA families from various manufacturers is accompanies by updates to FPGA bases. But you will have to study new documentation for the microcircuits families anyway.
Let's say we've chosen FPGA, studied (got familiar with) its specific features and are ready to create.
When creating a project, we can select the FPGA manufacturer, FPGA family, type of housing and number of elements. In addition, we can specify the components speed (to accurately set the Part Number).

Circuit > Board > FPGA

In FPGA, most contacts may be configured both for output and for input. It may seem great – just connect and do not bother. This one will be used for SD card controller connection, this one – for RGMII for Ethernet PHY and so on. But it's not so simple anyway. With such a fearless contacts assigning by convenience, we can come across many pitfalls. Documentation reading may help to avoid most of them, but contacts assigning won't be easier. And your board project may turn into an absolute mess.

Circuit > Board > FPGA

In this picture, everything is not so bad because it is created "artificially" based on an elaborated project. Usually, everything's not so smooth at first. And at FPGA addition stage, not all the elements are placed on the board. But it is specially marked that the signals from the lower left contact comes not to the bottom corner of the FPGA. As a result, they are intersected with other signals and when laid out may require both additional transition holes and additional board layers. This will increase the production costs in the end.

 

The contacts setting possibilities may also be limited. It's good if our board is created for one specific product. There are the outputs of adjacent elements, and we make response buses/signals for them in the FPGA. Then we launch a pilot CAD project for the FPGA. If everything's ok, the board may be laid out.

 

Some digression: AFAIK, Xilinx Spartan-6 had specially assigned pins for DDR memory that were then conveniently laid out subject to correct interrelation of microcircuits in the board. And it was unnecessary to move or swap them afterwards.

 

Often, specifications require some unification and our board will be used for several projects in the future. This is the way a core board with processor is designed for operation with many other devices, some kind of debugging board with FPGA, processor and OS "for friends". And there's much to think about. To provide one pin in the contact for synchronization or for PLL signal output if necessary. To determine the signals direction in the bus: input, output or both ways. If our core board is always a master, such signals to the address bus or control signals may work only for output.
If there's a response from the slave board on the bus such as WAIT or BUSY, they may be assigned to pins capable to work as outputs only. The same may be done with the pins determining the board availability.
At first sight, such assigning limits the possibilities of future laying out and signals shuffling. But in practice, it's better to know such restrictions in advance instead of assigning all the signals as Inout.

 

We can select a file to take the list of signals from. This may be a pilot project, a file at Verilog or VHDL.

Circuit > Board > FPGA

 

If we have not made any pilot project yet, we can do without compiling such a file. And then simply create the signals in a program window. Default signal types. For single and differential signals.
Then we can proceed and specify the location where to download the file with our contacts layout.
Then we need to understand the way we want our circuit to operate, either we need full-scale symbols or just lops in a circuit project will be enough with the description of all the contacts to be transmitted only in the form of a data share file with FPGA CAD system.
I always liked the option without any circuit elements when all the exchange is realized via unknown internal paths. But, when you work in a team, you have to accept more down-to-earth game rules. So, the corporate standard always dictated to divide a symbol between banks, to separate the loops for configuration, earthing, power and other. Such division has its pros, but there are some cons, too. It was me who had to make a circuit symbol. For FPGA with 484 contacts, it's not so difficult to make a correct circuit symbol, though it may seem complicated. However, for a microcircuit with 1172 contacts, this task becomes quite and exhausting one. Most contacts have long and similar names that may be confused easily. All the symbols may be generated automatically. But, then they fail to match the "corporative" preferences. In IOD, a symbol may be easily created from the elements data base simply by dragging it from the contacts list window to the symbol window. I cannot say it's as simple as playing in a Funny Farm, but at this stage, we just can assign signals to the microcircuit contacts using a mouse. This method also allows to set the way of labeling: by name, by function, by contact number or in any other way. Usually, I select labeling by function. To my mind, such label is more informative. So, you can always read from the circuit what kind of signal may be put in here.

Circuit > Board > FPGA

 

From my own observations, I can say that the last names in Xilinx (for series 6 and 7 families) are quite short and informative.
IO_L6N_T0_VREF_13
IO — input/output contact
L6N — differential pair
T0 — byte which allows internal data signals swap for memory (this is to be defined!)
VREF — here, external support voltage may be connected to if required by the standard of signal selected for the bank and there isn't any other possibility to connect in inside the FPGA.
13 — bank number.

Circuit > Board > FPGA

 

In Altera, adequate functional labels may also be found sometimes, though (it's my subjective opinion) some poorly reproducible contact names are more frequent that cannot be put into the circuit sheet. Perhaps, if I made circuits with large memory volumes, multipliers or some type of colliders, I would find such names useful.
IO_DIFFIO_T18p__DATA15_DQ3T0_X9__DQ3T9_X18_DQ5T27_X36
In this case, the possibility to assign a Custom Label for the contact name is helpful. Or the possibility to enter the necessary label manually. Usually, I copy the function and reduce it to the following:
IO_T18p_DATA15_DQ
Where
IO — may be used for input/output signals
T18p — is the number of differential pair in the upper segment
DATA15 — this contact may be used for parallel configuration downloading
DQ — for me, it's the abbreviated contact function (other options are DM and DQS)
This is one of the examples of a contact naming based on its functionality, and with some specific project, any other attribute will be used in the first place.
For instance, in Altera when LVDS signals are used, the external load should be placed first. For some banks, it is the load resistance at the receiving side only, for others, the output resistance is also required. This may be canceled in the circuit symbol in Custom Label property. The same is true for PCI type signals. 3.3V-PCI bus standard can be assigned not for all banks. This also may be included in the symbol. Despite this standard is more widely replaced with PCIe in desk top systems, it is still popular in production versions. And some customers look for this very version of units.
An inscription may be added in a symbol for all the contact at once. This will reduce the text inside the symbol. As any additional information may overload the symbol and circuit, a compromise is required. I did it for Xilinx microcircuits that had microcircuits compatible by contacts inside one and the same housing with different number of logical elements, but in "tiny" microcircuits some contacts are not active. For such project, a circuit was partially unsoldered and there was a possibility to put a "lighter" microcircuit. Taking this into account when assigning the contacts, later, you can save on the missing components and the FPGA price.
For convenience, I make the symbols divided into banks. An exclusion may be made for configuration contacts. For projects with complex synchronization structure, CLK inputs, local, global and other, may be collected into a separate symbol. VCCO bank power contacts are placed in the symbol together with the bank or in a separate symbol if the CHIEF designer wishes so.
Most often, I use separate symbols for the core power, VCCAUX, earthing and other contacts.
I heard, today, just a loop in the circuit may be created for all the power contacts in order not to overcharge it with the big number of typical contacts. It's not the way we do, therefore I have no experience in this options. Details of this may be found in reference documents or webinars and training materials at Mentor Graphics or its representatives sites.

 

I send the created symbols to the circuit project directly specifying the housing type and abstract it into the board, so the microcircuit is linked to the board, the circuit and the IODesigner.

Circuit > Board > FPGA

Signals creation and assignment
As it was described above, we can export the signals from a file or create them ourselves.

Circuit > Board > FPGA

Signals may be assigned both with a mouse or via import/export operations. Holding SHIFT, CTRL or ALT keys pressed, you can re-assign the signals to already assigned contacts. Or assign all the selected signals into one bank. Visually, the banks are displayed in different colors. Different type contacts are displayed by different icons. Differential pairs display may be switched on. With time, occupied signals are colored.

Circuit > Board > FPGA

After updating, we can see the symbols with the signals in the circuit.

Circuit > Board > FPGA

 

Then, we check their connection on the board. Usually, it's the same "mess" as was shown above.
Sometimes, I start with a simple list of signals to be automatically created in the system and then, using a circuit editor, I drag them to other elements.
Another alternative is to import the list of signals from the circuit.
Having synchronized the circuit project, the board and IO Designer, we can call the signals display in IO Designer window. With the loops coming from the FPGA to the components connected to it.
Now, we can comb our signals. And this will be an automatic operation according to the rules we set. Configuration signals will stay intact. In addition, we can preliminary lock the signals to prevent from their position changing.

Circuit > Board > FPGA

Please, note, DRAM3_RESET_B signal that must be assigned LVCMOS_1.35V input/output standard and cannot stay in the same bank with SSTL standard signals is assigned to bank 17, and all the rest of DRAM3* signals are assigned to bank 12. As the system has only four LVCMOS_1.35V signals, they are assigned LVCMOS1.8V standard with a level modifier.

Circuit > Board > FPGA

Despite seeming complexity, the signals are now arranged according to the set rules for more convenient operations with the project in Quartus.
In the picture, you can see the placed components and the lines stretching to them from the FPGA. Sometimes, if not all the components are placed, it is impossible to arrange all the contacts at once for failsafe laying out. Though, it depends on the task.
After such arrangement of contacts, you may pass the circuit to final laying out or make the layout yourself.
In addition, it may be exported to Verilog / VHDL file. Export in *.ucf, *.pin or other file is also possible. Give it to the FPGA designer for a pilot project, it may happen that something is omitted. However, in a small team, it not always works as your teammate may be very busy with other projects. (Old projects updates, new customer's desires or parallel projects.)
Limitations.
This method has it's own limitations and I do not have a universal answer for their bypassing. Mostly, they are related to the necessity of doing many things for unification and for future use. So, the crutches need to be invented. As the default Altera settings forbid placing a differential signal next to the differential signal, the compiler will give a warning. We can bypass it by placing SLEW_RATE = 0 MHz parameter into Pin Planner Quartus. Then, the compilation will be finished successfully, even if our real signal will have frequency of 20 MHz. In IODesigner, there isn't such a parameter. As a result, these contacts are engaged last in the circuit or I set such a signal type for them that avoids conflict, for example, PCB signal or configuration signal.
There are other limitation that are usually bypassed. But, generally, I take them as positive for they make you read the documentation for the microcircuit well in advance before the ready board comes.
For those who work in other designing systems, some items may seem unmarked or, maybe, unnecessary. So, as far as I know (heard), Altium allows for setting FPGA project compilation directly in the project with the circuit and board. I have no information about all its possibilities. And for people who design in it, no import to Quartus or ISE is required. But in our team, board project is made by one person, while FPGA project is the responsibility of another one. When passing the circuit for laying out, I try to give the most correct description of signals and leave some freedom for the board designer to change contacts. And we manage any possible warnings as they accumulate.
In the end, I'd like to mention that IO Designer is not a silver bullet. It does not turn the circuit, board and FPGA project design process into an interactive game and does not exempt you from reading the microcircuit documentation. However, it's much more pleasant to work with such instrument. The article does not uncover all its advantages. I also cannot say anything for sure about the libraries completeness for all the microcircuits for I have experience only with some of Altera and Хilinx families. I used to work a bit with Lattice debugging set, but it was not a circuit and, moreover, a board. I've never worked with Actel at all. As for the remarks for Xilinx, I can note that my version does not have direct constraints file transfer to/from Vivado. Maybe, it will appear in the updates. As it's not me, who manages the FPGA Xilinx project, I did not see into the problem. We coped with export function via *.csv file.
This post cannot be called a IODesigner guide. For this see Mentor Graphics lessons. I know, that Megratec company offers some training in Russian. www.megratec.ru.
I also know Mentor Graphics prepares a new version of designing system, xPedition, for marketing. We'll see what will be added for IODesigner. Out of the presentations I saw, I was impressed by 3D boards display updates and designing of units with several boards in a single project.
Besides the CADs I mentioned, there are other systems for PC boards. Each one has its advantages and the list of "Y items missing compared to X". And if I said nothing about their advantages compared to IOD alternative, please, don't take it personally. You may speak about it in the comments. Or write an article about your way to design FPGA in your CAD system.

 

GSM-gateways Polygator at conference «Corporate Communication Systems»

«Polygator» equipment will be presented at international conference «Corporate Communication Systems» (Kiev, Ukraine) on October 15th, 2014. Other famous equipment manufacturers, distributors and system integrators will also participate in this event.


Our company will present produced GSM-gateways and SIM-bank to conference participants as well as make a short presentation named «Usage of VoIP GSM/CDMA gateways in corporate telephony».


More details about conference (rus)

Quick contact


 

Contact Details

POLYGATOR (manufacturer)

This email address is being protected from spambots. You need JavaScript enabled to view it.
www.polygator.com
Skypepolygator

 

Dealer contacts:

UKRAINE
Elgato Communications
+380(63)797-3020 (mob)
+380(56)719-9030 (tel./fax office)

Local landlines

RUSSIA
+7(499)403-3248 (Moscow)
UK
+44(203)769-1858 (London)
USA
+1(312)3-400-898 (Chicago)

 

Compatibility Short-list

Native drivers Certified with Tested with Technologies
Asterisk
(PCI GSM Interface Card for 4/8 SIM-cards)

Elastix

SoftSwitch, IP-PBX
Asterisk
3CX
Oktell

VoIP Billing
MVTS
A2Billing
MOR

SMS software
Diafaan
Kannel
Ozeki
ActivExperts
SMS.Gate

GSM UMTS PRI(E1) SMS

SIP

Codecs
G.729 G.711 G.723 G.726 DTMF

SMS protocols
SMPP SMTP AT-commands SMS-via-SQLLite (Under Asterisk)

+ Dev by abc7